java - memoria compartida distribuida pdf

Elegir una solución de memoria compartida distribuida

Question

Tengo la tarea de crear un prototipo para una aplicación de memoria compartida distribuida (DSM) escalable de forma masiva. El prototipo solo serviría como prueba de concepto, pero quiero dedicar mi tiempo de manera más eficaz al elegir los componentes que se utilizarán en la solución real más adelante.

El objetivo de esta solución es tomar la entrada de datos de una fuente externa, batirla y hacer que el resultado esté disponible para una serie de interfaces. Esos "frontends" solo tomarían los datos del caché y los servirían sin procesamiento adicional. La cantidad de visitas frontales a estos datos puede ser literalmente de millones por segundo.

Los datos en sí son muy volátiles; puede (y lo hace) cambiar muy rápidamente. Sin embargo, las interfaces deberían ver datos "antiguos" hasta que el más nuevo se haya procesado y almacenado en caché. El procesamiento y la escritura se realizan mediante un solo nodo (redundante), mientras que otros nodos solo leen los datos. En otras palabras: no hay comportamiento de lectura.

Estaba buscando soluciones como memcached, sin embargo, esta en particular no cumple con todos nuestros requisitos que se enumeran a continuación:

1. La solución debe tener al menos una API de cliente Java que esté razonablemente bien mantenida, ya que el resto de la aplicación está escrita en Java y somos desarrolladores Java experimentados;
2. La solución debe ser totalmente elástica : debe ser posible agregar nuevos nodos sin reiniciar otros nodos en el clúster;
3. La solución debe ser capaz de manejar la conmutación por error . Sí, me doy cuenta de que esto significa algo de sobrecarga, pero el tamaño de los datos servidos en general no es grande (1G máximo), por lo que no debería ser un problema Por "conmutación por error", me refiero a la ejecución sin interrupciones sin codificación / cambio de las direcciones IP del servidor, como en los clientes de memcached cuando un nodo falla;
4. Idealmente, debería ser posible especificar el grado de superposición de datos (por ejemplo, cuántas copias de los mismos datos deben almacenarse en el grupo de DSM);
5. No es necesario almacenar permanentemente todos los datos, pero puede ser necesario realizar un procesamiento posterior de algunos de los datos (por ejemplo, la serialización de la base de datos).
6. Precio Obviamente, preferimos el código libre / abierto, pero nos complace pagar una cantidad razonable si una solución vale la pena. De cualquier manera, el contrato de soporte de 24 horas al día es obligatorio.
7. Todo tiene que estar alojado en nuestros centros de datos para que las ofertas de SaaS como Amazon SimpleDB queden fuera del alcance. Solo consideraríamos esto si no hubiera otras opciones disponibles.
8. Idealmente, la solución sería estrictamente consistente (como en CAP); sin embargo, la consistencia eventual puede ser considerada como una opción.

Gracias de antemano por cualquier idea.

Answer 1

¿Has pensado en usar una solución de mensajería estándar como rabbitmq ? RabbitMQ es una implementación de código abierto del protocolo AMQP .

Su aplicación se parece más o menos a un sistema de publicación / suscripción. El nodo de Publisher es el que realiza el procesamiento y coloca los mensajes (datos procesados) en una cola en los servidores. Los suscriptores pueden recibir mensajes del servidor de varias maneras. AMQP desacopla al productor y al consumidor de mensajes y es muy flexible en la forma en que puede combinar las dos partes.

Answer 2

Dependiendo de lo que prefieras, seguramente seguiría a los demás sugiriendo Hazelcast si te diriges a AP desde el teorema de CAP, pero si necesitas CP, elegiría Redis

Answer 3

Echa un vistazo a Hazelcast . Es un producto de cuadrícula de datos en la memoria altamente escalable y de código abierto (licencia de Apache). Ofrece soporte 7X24. Y resuelve todos tus problemas. Traté de explicar cada uno de ellos a continuación:

1. Tiene un cliente Java nativo.
2. Es 100% dinámico. Agregar y eliminar nodos dinámicamente. No hay necesidad de cambiar nada.
3. De nuevo todo es dinámico.
4. Puede configurar el número de nodos de copia de seguridad.
5. Hazelcast apoyo a la persistencia.
6. Todo lo que ofrece Hazelcast es gratuito (código abierto) y ofrece soporte a nivel empresarial.
7. Hazelcast es un archivo jar único. super facil de usar Solo agrega jar a tu ruta de clase. Echa un vistazo a la pantalla emitida en la página principal.
8. Hazelcast es estrictamente consistente. Nunca puedes leer datos antiguos.

Answer 4

Eche un vistazo a la agrupación JVM de Terracotta, es OpenSource;) No tiene API mientras funciona de manera eficiente a nivel JVM, cuando almacena el valor en un objeto replicado, se envía a todos los demás nodos. Incluso el bloqueo y todas esas cosas funcionan de manera transparente y sin agregar ningún código nuevo.

Answer 5

El caso de uso especificado parece encajar en el Hollow de Netflix. Este es un caché replicado de solo lectura con un solo productor y múltiples consumidores.

Answer 6

Es posible que desee comprobar soluciones específicas de Java como Coherence: http://www.oracle.com/global/ru/products/middleware/coherence/index.html

Sin embargo, considero que tales soluciones son demasiado complejas y prefiero usar soluciones como memcached. La gran desventaja de memcached para su propósito es la falta de bloqueo de registros que parece y no hay una forma integrada de replicar los datos para la conmutación por error. Es por eso que miraría en los almacenes de datos clave-valor. Muchos de ellos satisfacen tu necesidad por completo.

Aquí hay una lista de almacenes de datos clave-valor que pueden ayudarlo con su tarea: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores Simplemente elija uno con que te sientas cómodo.

Answer 7

Estoy haciendo un proyecto similar, pero en lugar de eso estoy apuntando a la plataforma .NET. Aparte de las soluciones ya mencionadas, creo que debería echar un vistazo a ScaleOut StateServer y Alachisoft NCache . Me temo que ninguna de estas alternativas es barata, pero son una apuesta más segura que el código abierto para soluciones comerciales según mi criterio.

1. Ambos proporcionan API de cliente de Java, aunque solo he jugado con las API de .NET.
2. StateServer cuenta con autodescubrimiento de nuevos nodos de caché, y NCache tiene una consola de administración donde se pueden agregar nuevos nodos de caché.
3. Ambos deben ser capaces de manejar fallos sin problemas.
4. StateServer puede tener 1 o 2 copias pasivas de los datos. NCache presenta más topologías de caché para elegir.
5. Si quiere decir escritura directa / escritura diferida en una base de datos que está disponible en ambas.
6. No tengo idea de cuántos servidores de caché planea usar, pero aquí están las especificaciones de precios completas: ScaleOut StateServer Alachisoft NCache
7. Ambos se instalan y configuran localmente en su servidor y ambos tienen Administración de GUI.
8. No estoy seguro exactamente de lo que implica lo estrictamente consistente, así que lo dejo para que investigue ...

En general, StateServer es la mejor opción si desea omitir la configuración de cada pequeño detalle en el clúster de caché, mientras que NCache presenta muchas características y topologías de caché para elegir.

Dependiendo del comportamiento de los datos hacia los clientes (si los datos se leen muchas veces desde el mismo cliente), puede ser una buena idea combinar el almacenamiento en caché local en los clientes con el almacenamiento en caché distribuido en el clúster (disponible para NCache y StateServer) , solo un pensamiento.

Answer 8

Le sugiero que use Redisson - Cuadrícula de datos en memoria basada en Redis para Java. Implementa ( BitSet , BloomFilter , Set , SortedSet , Map , ConcurrentMap , List , Queue , Deque , BlockingQueue , BlockingDeque , ReadWriteLock , Semaphore , Lock , AtomicLong , AtomicLong , CountDownLatch Publish / Subscribe , Publish / Subscribe , RemoteService , ExecutorService , LiveObjectService ) ¡servidor! Es compatible con los modos maestro / esclavo, centinela y servidor de clúster. También se admite el descubrimiento automático de topología de servidores de cluster / sentinel. Esta lib es gratuita y de código abierto.

Funciona perfectamente en la nube gracias al soporte AWS Elasticache.