Control de Concurrencia Distribuida

Usamos Terracota, así que me gustaría votar a favor.

He estado siguiendo Hazelcast y parece otra tecnología prometedora, pero no puedo votar por ella ya que no la he utilizado, y sabiendo que utiliza un sistema basado en P2P en su oído, realmente no confiaría en él para grandes necesidades de escala.

Pero también he oído hablar de Zookeeper, que salió de Yahoo, y se está moviendo bajo el paraguas de Hadoop. Si eres aventurero probando alguna nueva tecnología, esto realmente tiene un montón de promételo ya que es muy delgado y mezquino, centrándose solo en la coordinación. Me gusta la visión y la promesa, aunque podría ser demasiado verde todavía.

• http://www.terracotta.org
• http://wiki.apache.org/hadoop/ZooKeeper
• http://www.hazelcast.com

Terracotta está más cerca de un modelo "estratificado": todas las aplicaciones cliente hablan con una matriz de servidores Terracotta (y lo más importante para la escala, no se hablan entre sí). El Array Terracotta Server es capaz de ser agrupado tanto para la escala como para la disponibilidad (mirrored, para la disponibilidad, y striped, para la escala).

En cualquier caso, como probablemente sepa, Terracotta le da la capacidad de expresar concurrencia a través del clúster de la misma manera que lo hace en una sola JVM mediante el uso de POJO sincronizado / esperar / notificar o utilizando cualquiera de los java.útil.primitivas concurrentes como ReentrantReadWriteLock, CyclicBarrier, AtomicLong, FutureTask y así sucesivamente.

Hay muchas recetas simples que demuestran el uso de estas primitivas en el Libro de cocina de Terracota.

Como ejemplo, publicaré el ejemplo ReentrantReadWriteLock (tenga en cuenta que no hay una versión "Terracota" del bloqueo, solo use Java ReentrantReadWriteLock normal)

import java.util.concurrent.locks.*;

public class Main
{
    public static final Main instance = new Main();
    private int counter = 0;
    private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(true);

    public void read()
    {
        while (true) {
            rwl.readLock().lock();
                try {
                System.out.println("Counter is " + counter);
            } finally {
                rwl.readLock().unlock();
            }
            try { Thread.currentThread().sleep(1000); } catch (InterruptedException ie) {  }
        }
    }

    public void write()
    {
        while (true) {
            rwl.writeLock().lock();
            try {
               counter++;
               System.out.println("Incrementing counter.  Counter is " + counter);
            } finally {
                 rwl.writeLock().unlock();
            }
            try { Thread.currentThread().sleep(3000); } catch (InterruptedException ie) {  }
        }
    }

    public static void main(String[] args)
    {
        if (args.length > 0)  {
            // args --> Writer
            instance.write();
        } else {
            // no args --> Reader
            instance.read();
        }
    }
}

Recomiendo usar Redisson. Implementa más de 30 estructuras y servicios de datos distribuidos, incluyendo java.util.Lock. Ejemplo de uso:

Config config = new Config();
config.addAddress("some.server.com:8291");
Redisson redisson = Redisson.create(config);

Lock lock = redisson.getLock("anyLock");
lock.lock();
try {
    ...
} finally {
   lock.unlock();
}

redisson.shutdown();

Iba a aconsejar sobre el uso de memcached como un almacenamiento RAM muy rápido y distribuido para mantener registros; pero parece que EHCache es un proyecto similar pero más centrado en java.

Cualquiera de los dos es el camino a seguir, siempre y cuando esté seguro de usar actualizaciones atómicas (memcached las soporta, no sabe sobre EHCache). Es, con mucho, la solución más escalable.

Como punto de datos relacionado, Google utiliza 'Chubby', un almacenamiento de bloqueo distribuido rápido basado en RAM como la raíz de varios sistemas, entre ellos BigTable.

He hecho mucho trabajo con Coherence, lo que permitió varios enfoques para implementar un bloqueo distribuido. El enfoque ingenuo fue solicitar bloquear el mismo objeto lógico en todos los nodos participantes. En términos de coherencia, esto estaba bloqueando una clave en una caché replicada. Este enfoque no escala tan bien porque el tráfico de red aumenta linealmente a medida que agrega nodos. Una forma más inteligente era usar una caché distribuida, donde cada nodo en el clúster es naturalmente responsable de una parte de el espacio de claves, por lo que bloquear una clave en una caché de este tipo siempre implicaba la comunicación con, como máximo, un nodo. Usted podría rodar su propio acercamiento basado en esta idea, o mejor aún, conseguir Coherencia. Realmente es el kit de herramientas de escalabilidad de sus sueños.

Yo añadiría que cualquier mecanismo de bloqueo basado en la red multi-nodo medio decente tendría que ser razonablemente sofisticado para actuar correctamente en el caso de cualquier fallo de la red.

¿No está seguro de si entiendo todo el contexto, pero suena como si tuviera 1 base de datos única respaldando esto? ¿Por qué no hacer uso del bloqueo de la base de datos: si la creación del cliente es una sola INSERCIÓN, entonces esta declaración por sí sola puede servir como un bloqueo, ya que la base de datos rechazará una segunda INSERCIÓN que violaría una de sus restricciones (por ejemplo, el hecho de que el nombre del cliente es único, por ejemplo).

Si la operación" inserción de un cliente " no es atómica y es un lote de declaraciones, entonces Introduciría (o usaría) una INSERCIÓN inicial que crea un registro básico simple que identifica a su cliente (con las restricciones de singularidad necesarias) y luego haría todas las otras inserciones/actualizaciones en la misma transacción. Una vez más, la base de datos se encargará de la coherencia y cualquier modificación concurrente resultará en que una de ellas falle.

Hice un servicio RMI simple con dos métodos: bloquear y liberar. ambos métodos toman una clave (mi modelo de datos utiliza UUIDs como pk por lo que también era la clave de bloqueo).

RMI es una buena solución para esto porque está centralizado. no puede hacer esto con EJBs (especialmente en un clúster, ya que no sabe en qué máquina aterrizará su llamada). además, es fácil.

Funcionó para mí.

Si puede configurar su equilibrio de carga para que las solicitudes de un solo cliente siempre se asignen al mismo servidor, entonces puede manejar esto a través de la sincronización local. Por ejemplo, tome su ID de cliente mod 10 para encontrar cuál de los 10 nodos usar.

Incluso si no desea hacer esto en el caso general, sus nodos podrían proxy entre sí para este tipo específico de solicitud.

Asumiendo que tus usuarios son lo suficientemente uniformes (es decir, si tienes un montón de ellos) que no esperas puntos calientes para aparecer donde un nodo se sobrecarga, esto aún debería escalar bastante bien.

También podría considerar Cacheonix para bloqueos distribuidos. A diferencia de cualquier otra cosa mencionada aquí Cacheonix soporta bloqueos ReadWrite con escalado de bloqueo de lectura a escritura cuando sea necesario:

ReadWriteLock rwLock = Cacheonix.getInstance().getCluster().getReadWriteLock();
Lock lock = rwLock.getWriteLock();
try {
  ...
} finally {
  lock.unlock();
}

Divulgación completa: Soy un desarrollador de Cacheonix.

Dado que ya se está conectando a una base de datos, antes de agregar otra pieza infra, eche un vistazo a JdbcSemaphore , es fácil de usar:

JdbcSemaphore semaphore = new JdbcSemaphore(ds, semName, maxReservations);
boolean acq = semaphore.acquire(acquire, 1, TimeUnit.MINUTES);
if (acq) {
 // do stuff
 semaphore.release();
} else {
  throw new TimeoutException();
}

Es parte de la biblioteca spf4j.

Antes, usábamos un "servidor de bloqueo" específico en la red para manejar esto. Bleh.

Su servidor de base de datos puede tener recursos específicamente para hacer este tipo de cosas. MS-SQL Server tiene bloqueos de aplicaciones utilizables a través del sp_getaplock/procedimientos sp_releaseapplock.

Hemos estado desarrollando un framework de sincronización distribuida de código abierto, actualmente DistributedReentrantLock y DistributedReentrantReadWrite lock se ha implementado, pero todavía están en fase de prueba y refactorización. En nuestra arquitectura, las teclas de bloqueo se dividen en cubos y cada nodo es resonable para cierto número de cubos. Tan efectivamente para una solicitud de bloqueo exitosa, solo hay una solicitud de red. También estamos utilizando la clase AbstractQueuedSynchronizer como estado de bloqueo local, por lo tanto, todas las solicitudes de bloqueo fallidas se manejan localmente, esto reduce drásticamente el tráfico de red. Estamos usando JGroups ( http://jgroups.org ) para comunicación grupal y Hessian para serialización.

Para obtener más información, consulte http://code.google.com/p/vitrit/.

Por favor envíenme sus valiosos comentarios.

Kamran