Распределенное управление совместным выполнением

Назад в день, мы использовали бы определенный "сервер блокировки" в сети для обработки этого. Bleh.

Ваш сервер базы данных мог бы иметь ресурсы специально для выполнения такого рода вещи. SQL SERVER MS имеет блокировки приложения, применимые через sp_getapplock / sp_releaseapplock процедуры.

Я сделал простой сервис RMI с двумя методами: блокировка и выпуск. оба метода берут ключ (моя модель данных использовала UUID в качестве pk так, чтобы был также ключ блокировки).

RMI является хорошим решением для этого, потому что он централизован. Вы не можете сделать этого с EJBs (specialially в кластере, поскольку Вы не знаете, на которую машину Ваш вызов приземлится). плюс, это легко.

это работало на меня.

Если можно настроить выравнивание нагрузки так, чтобы запросы на единственного клиента всегда были отображены на том же сервере тогда, можно обработать это через локальную синхронизацию. Например, возьмите свою модификацию идентификатора клиента 10, чтобы найти который из этих 10 узлов использовать.

, Даже если Вы не хотите делать это в общем случае, который Ваши узлы могли бы проксировать друг другу для этого определенного типа запроса.

Принятие Ваших пользователей достаточно универсально (т.е. если у Вас есть тонна их), что Вы не ожидаете, что горячие точки откроются, где один узел перегружается, это должно все еще масштабироваться вполне прилично.

Я сделал большую работу с Когерентностью, которая позволила несколько подходов к реализации распределенной блокировки. Наивный подход должен был запросить заблокировать тот же логический объект на всех участвующих узлах. В терминах Когерентности это блокировало ключ на Дублируемом Кэше. Этот подход не масштабирует это хорошо, потому что сетевой трафик увеличивается линейно, поскольку Вы добавляете узлы. Более умный путь состоял в том, чтобы использовать Распределенный Кэш, где каждый узел в кластере естественно ответственен за часть ключевого пространства, таким образом блокирование ключа в таком кэше всегда включало связь с самое большее одним узлом. Вы могли самокрутка приближаться на основе этой идеи, или лучше все еще, получать Когерентность. Это действительно - инструментарий масштабируемости Ваших мечтаний.

я добавил бы, что любая половина достойного мультиузла основанный на сети механизм блокировки должна будет быть довольно сложной для действия правильно в случае любого отказа сети.

Я шел в совет относительно использования memcached как очень быстрое, распределенное устройство хранения данных RAM для хранения журналов; но кажется, что EHCache является подобным проектом, но более центральный Java.

Любой является способом пойти, пока Вы, несомненно, будете использовать атомарные обновления (memcached, поддерживает их, не знайте о EHCache). Это - безусловно большая часть масштабируемого решения.

Как связанная точка данных, 'Полное' использование Google, быстрое, основанное на RAM распределенное устройство хранения данных блокировки как корень нескольких систем, среди них BigTable.

Терракота ближе к "многоуровневой" модели - все клиентские приложения говорят с Терракотовым Массивом Сервера (и что еще более важно для масштаба они не говорят друг с другом). Терракотовый Массив Сервера способен к тому, чтобы быть кластеризируемым и для масштаба и для доступности (зеркально отраженный, для доступности, и чередуемый, для масштаба).

В любом случае, поскольку Вы, вероятно, знаете, что Терракота дает Вам способность выразить параллелизм через кластер тем же путем, Вы делаете в единственной JVM при помощи POJO, синхронизировался/ожидал/уведомлял или при помощи любого из java.util.concurrent примитивов, таких как ReentrantReadWriteLock, CyclicBarrier, AtomicLong, FutureTask и так далее.

существует много простых рецептов, демонстрирующих использование этих примитивов в Терракотовая Поваренная книга .

Как пример, я отправлю пример ReentrantReadWriteLock (примечание нет никакой "Терракотовой" версии блокировки - Вы просто используете нормальный 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();
        }
    }
}

Мы используем Терракоту, таким образом, я хотел бы голосовать за это.

я следовал за Hazelcast, и он похож на другую многообещающую технологию, но не может голосовать за него, так как я не использовал его, и зная, что он использует базирующуюся систему P2P в своем услышанном, я действительно не буду доверять ему для больших потребностей масштабирования.

, Но я также услышал о Служителе зоопарка, который вышел из Yahoo и перемещается под защитой Hadoop. Если Вы - предприимчивое испытание некоторой новой технологии, это действительно имеет большое обещание, так как это является очень минимизированным и средним, фокусируясь на просто координации. Мне нравятся видение и обещание, хотя это могло бы быть слишком зелено все еще.

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

Не уверенный, если я понимаю весь контекст, но он кажется, что у Вас есть 1 единая база данных, поддерживающая это? Почему бы не использовать блокировку базы данных: если созданием клиента является единственная ВСТАВКА тогда, один только этот оператор может служить блокировкой, так как база данных отклонит вторую ВСТАВКУ, которая нарушила бы одно из Ваших ограничений (например, то, что имя клиента уникально, например).

, Если бы "вставка клиента" операция не является атомарной и является пакетом операторов тогда, я представил бы (или использование) начальную ВСТАВКУ, которая создает некоторое простое личное дело, идентифицирующее Вашего клиента (с необходимыми ограничениями УНИКАЛЬНОСТИ), и затем сделайте все другие, вставляет/обновляет в ту же транзакцию. Снова база данных будет заботиться о непротиворечивости, и любые параллельные модификации приведут к одному из них сбой.

Мы разрабатываем среду распределенной синхронизации с открытым исходным кодом, в настоящее время реализована блокировка DistributedReentrantLock и DistributedReentrantReadWrite, но все еще на стадии тестирования и рефакторинга. В нашей архитектуре ключи блокировки разделены на сегменты, и каждый узел отвечает за определенное количество сегментов. Таким образом, для успешного запроса блокировки существует только один сетевой запрос. Мы также используем класс AbstractQueuedSynchronizer в качестве состояния локальной блокировки, поэтому все неудавшиеся запросы блокировки обрабатываются локально, что резко снижает сетевой трафик. Мы используем JGroups ( http://jgroups.org ) для группового взаимодействия и Hessian для сериализации.

подробнее см. На http://code.google.com/p/vitrit/ .

Пожалуйста, пришлите мне ваш ценный отзыв.

Камран