Разрешение конфликтов в распределенном списке

Question

Я хотел бы сохранить список объектов, распределенных между N балансированными по балансу серверами: всякий раз, когда клиент меняет список на одном сервере, я бы хотел, чтобы эти изменения переносились на другие серверы. Итак, я думаю, это случай репликации мастер-мастера. Каков самый простой способ справиться с этим? Один из упрощающих фактов состоит в том, что каждое изменение объекта в списке имеет связанный с ним увеличивающийся номер версии, прикрепленный к нему. Таким образом, можно разрешить конфликты, если элемент был изменен на двух разных серверах, и эти две дельты попадают на третий сервер.

Редактировать: уточнение: Я хорошо знаком с распределенными хранилищами ключевого значения, такими как Memcached и Redis. Это не проблема здесь; меня интересует механизм разрешения конфликтов в общем списке: если сервер A изменяет элемент в списке, а сервер B удаляет элемент, например, как разрешить конфликт программно.

Answer 1

Оставьте свои изменения в очереди. Попросите каждого сервера смотреть в очередь и действовать на него.

Например, очередь может иметь:

• добавить пункт # 33
• удалить элемент # 55
• пункт Обновление # 22
• и так далее

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

Я сделал базу данных в памяти с таким методом, и он отлично работал на нескольких «серверах».

EDIT:

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

Каждый сервер, что обновления положит UPDATE (или ADD или DELETE) запрос в очереди для всех других серверов. Каждый сервер также должен хранить список запрошенных в очереди запросов, исходящих от него, чтобы он не загружал свои собственные обновления из очереди.

Answer 2

Предлагаю memcached. Это распределенная система кеша сервера, которая, по-видимому, идеально соответствует вашим потребностям. Проверить эту ссылку:

Which .NET Memcached client do you use, EnyimMemcached vs. BeITMemcached?

Если проходя весь список вас не устраивает (я не знаю, если Memcached достаточно умен, чтобы дифф списки), то я предложил бы давая старый DataSet объект а посмотрите, так как его diff-граммы должны хорошо подходить для передачи только дельт, если ваш набор данных большой.

Answer 3

Если вы находитесь на платформе Windows, я предлагаю вам взглянуть на «Windows Server AppFabric» и особенно функцию Caching. Зовут фанк, но я думаю, что это именно то, что вы ищете, я цитирую:

Распределенная в памяти кэш, который обеспечивает .NET-приложений с доступом высокоскоростной, окалины и высокая доступность, Данные Приложения.

Answer 4

У каждого сервера есть собственная версия List локально кэшированных или вы планируете использовать централизованный слой кеширования?

Как и было предложено, у вас может быть централизованный процесс «push», который работает с централизованной очередью. Любые изменения, представленные любым сервером, помещаются в очередь, а процесс «push» может вызывать обновления для всех серверов через некоторый механизм удаленного доступа/WebService.

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

Я видел, как это реализовано как служба Windows, которая имеет внутреннюю очередь (может сохраняться в асинхронном режиме DB для обеспечения отказоустойчивости), которая управляет очередью и просто берет элементы один за другим, проверяет элемент, изменение/содержание журналов и наконец, подталкивает его к локальным List с помощью запросов WebService на каждый веб-сервер (серверы поддерживают список в памяти, который просто обновляется/добавляется/удаляется по мере необходимости).

Answer 5

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

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

Я рекомендую вам использовать Lamport Clocks.