Rozproszona Kontrola Współbieżności

Używamy terakoty, więc chciałbym za tym zagłosować.

Śledziłem Hazelcast i wygląda to na kolejną obiecującą technologię, ale nie mogę na nią głosować, ponieważ nie korzystałem z niej, a wiedząc, że używa systemu opartego na P2P, naprawdę nie ufałbym mu w przypadku dużych potrzeb skalowania.

Ale słyszałem też o Zookeeper, który wyszedł z Yahoo i porusza się pod parasolem Hadoop. Jeśli szukasz przygód, wypróbuj nową technologię, która naprawdę ma wiele obietnica, ponieważ jest bardzo chuda i wredna, koncentrując się na koordynacji. Podoba mi się ta wizja i obietnica, choć może być jeszcze zbyt Zielona.

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

Terracotta jest bliższa modelowi "warstwowemu" - wszystkie aplikacje klienckie rozmawiają z tablicą serwerów Terracotta(a co ważniejsze ze względu na skalę nie rozmawiają ze sobą). Tablica serwerów Terracotta może być grupowana zarówno pod kątem skali ,jak i dostępności (lustrzana, dla dostępności i paski, dla skali).

W każdym przypadku, jak zapewne wiesz, Terracotta daje możliwość wyrażania współbieżności w całym klastrze w taki sam sposób, jak w pojedynczym JVM za pomocą POJO synchronized / wait/notify or by using any of the java.util.współbieżne prymitywy, takie jak ReentrantReadWriteLock, CyclicBarrier, AtomicLong, FutureTask i tak dalej.

Istnieje wiele prostych przepisów demonstrujących użycie tych prymitywów w Terakotowej książce kucharskiej .

Jako przykład podam przykład ReentrantReadWriteLock (zauważ, że nie ma wersji "Terakotowej" blokady - wystarczy użyć zwykłego Java ReentrantReadWriteLock)

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();
        }
    }
}

Zalecam użycie Redisson . Implementuje ponad 30 rozproszonych struktur danych i usług, w tym java.util.Lock. Przykład użycia:

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();

Miałem zamiar doradzić, jak używać memcached jako bardzo szybkiej, rozproszonej pamięci RAM do przechowywania dzienników; ale wygląda na to, że EHCache jest podobnym projektem, ale bardziej zorientowanym na Javę.

Jedno i drugie jest do zrobienia, o ile na pewno używasz atomic updates(memcached je obsługuje, Nie wiem o EHCache). To zdecydowanie najbardziej skalowalne rozwiązanie.

Jako pokrewny datapoint, Google używa "Chubby", szybkiej, opartej na PAMIĘCI RAM pamięci rozproszonej jako źródła wielu systemów, wśród nich BigTable.

Wykonałem wiele pracy z Koherencją, co pozwoliło na kilka podejść do implementacji rozproszonej blokady. Naiwne podejście polegało na żądaniu zablokowania tego samego obiektu logicznego we wszystkich uczestniczących węzłach. W sensie spójności było to blokowanie klucza na replikowanym buforze. To podejście nie skaluje się tak dobrze, ponieważ ruch sieciowy zwiększa się liniowo wraz z dodaniem węzłów. Inteligentniejszym sposobem było użycie rozproszonej pamięci podręcznej, gdzie każdy węzeł w klastrze jest naturalnie odpowiedzialny za część przestrzeń klucza, więc blokowanie klucza w takiej pamięci podręcznej zawsze wiązało się z komunikacją z co najwyżej jednym węzłem. W oparciu o tę ideę można stworzyć własne podejście, albo jeszcze lepiej uzyskać spójność. To naprawdę jest zestaw narzędzi skalowalności Twoich marzeń.

Dodam, że każdy w połowie przyzwoity mechanizm blokowania oparty na wielu węzłach sieci musiałby być odpowiednio wyrafinowany, aby działać poprawnie w przypadku jakiejkolwiek awarii sieci.

Nie wiem, czy Rozumiem cały kontekst, ale wygląda na to, że masz jedną bazę danych popierającą to? Dlaczego nie skorzystać z blokowania bazy danych: jeśli tworzenie klienta jest pojedynczym INSERTEM, to samo polecenie może służyć jako blokada, ponieważ baza danych odrzuci drugi INSERT, który naruszyłby jedno z Twoich ograniczeń (np. fakt, że nazwa klienta jest unikalna).

Jeśli operacja "wstawianie klienta" nie jest atomowa i jest zbiorem instrukcji, to Chciałbym wprowadzić (lub użyć) początkową wstawkę, która tworzy jakiś prosty podstawowy rekord identyfikujący klienta (z niezbędnymi ograniczeniami unikalności), a następnie zrobić wszystkie inne wstawki / aktualizacje w tej samej transakcji. Ponownie baza danych zadba o spójność i wszelkie współbieżne modyfikacje spowodują, że jedna z nich ulegnie awarii.

Wykonałem prostą usługę RMI za pomocą dwóch metod: lock i release. obie metody przyjmują klucz (mój model danych używał uuid jako pk, więc był to również klucz blokujący).

RMI jest dobrym rozwiązaniem, ponieważ jest scentralizowany. nie możesz tego zrobić z EJBs(szczególnie w klastrze, ponieważ nie wiesz, na której maszynie wyląduje Twoje połączenie). plus, to proste.

U mnie zadziałało.

Jeśli możesz skonfigurować równoważenie obciążenia tak, aby żądania dla jednego klienta zawsze były mapowane na ten sam serwer, możesz obsłużyć to poprzez lokalną synchronizację. Na przykład, weź identyfikator klienta mod 10, aby znaleźć, które z węzłów 10 użyć.

Nawet jeśli nie chcesz tego robić w ogólnym przypadku, twoje węzły mogą zastępować się nawzajem dla tego konkretnego typu żądania.

Zakładając, że Twoi użytkownicy są na tyle jednorodni (tj. jeśli masz ich mnóstwo) , że nie oczekujesz gorące miejsca, które pojawią się, gdy jeden węzeł zostanie przeciążony, to nadal powinno być dobrze skalowane.

Możesz również rozważyć Cacheonix dla rozproszonych zamków. Cacheonix obsługuje blokady ReadWrite z eskalacją blokady od odczytu do zapisu w razie potrzeby:

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

Pełne ujawnienie: jestem programistą Cacheonix.

Ponieważ już łączysz się z bazą danych, przed dodaniem kolejnego elementu na podczerwień, spójrz na JdbcSemaphore , jest prosty w użyciu:

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();
}

Jest częścią biblioteki spf4j .

Kiedyś używaliśmy do tego konkretnego "serwera blokującego" w sieci. Bleh.

Twój serwer bazy danych może mieć zasoby specjalnie do tego rodzaju rzeczy. MS-SQL Server posiada blokadę aplikacji używaną przez sp_getapplock/procedury sp_releaseapplock.

Rozwijaliśmy open source, rozproszony Framework synchronizacji, obecnie DistributedReentrantLock i DistributedReentrantReadWrite blokada została zaimplementowana, ale nadal są w fazie testowania i refaktoryzacji. W naszej architekturze klucze blokujące są dzielone w wiadra i każdy węzeł jest rezonowalny dla określonej liczby wiadra. Tak więc dla pomyślnego żądania blokady istnieje tylko jedno żądanie sieciowe. Używamy również klasy AbstractQueuedSynchronizer jako local lock state, tak więc wszystkie nieudane żądania blokady są obsługiwane lokalnie, co drastycznie zmniejsza trafic sieci. Używamy JGroups (http://jgroups.org ) do komunikacji grupowej i Heski do serializacji.

Aby uzyskać więcej informacji, sprawdź http://code.google.com/p/vitrit/.

Prześlij mi swoją cenną opinię.

Kamran