Когда использовать Paxos (реальные практические примеры использования)?

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

Является ли следующий вариант использования Paxos?

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

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

ОТВЕТЫ

Ответ 2

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

Однако состояние ваших серверов также зависит от действий пользователя. Например, если пользователь решил повысить на 50 $- ваш сервер должен где-то хранить эту информацию. Теперь предположим, что ваш сервер ответил "хорошо" на веб-клиента (я предполагаю, что в Интернете игра в покер), а затем сервер разбился. На других серверах может не быть информации о 50 $рейзе, и ваша система будет непоследовательна (в том смысле, что клиент считает, что 50 $рейз был сделан, а оставшиеся серверы не замечают этого).

Обратите внимание, что большинство здесь не поможет, так как данные теряются. Более того, предположим, что вместо основного сбоя сервера главный сервер плюс еще один получил данные с повышением на 50 $. В этом случае использование большинства может быть даже хуже: если вы получите ответ от двух серверов с данными, вы подумаете, что было выполнено 50 $рейз. Но если один из них потерпит неудачу, тогда у вас не будет большинства, и вы подумаете, что рейз не был выполнен.

В целом, Paxos может использоваться для репликации конечного автомата с отказоустойчивым способом. Если "конечный автомат" можно рассматривать как алгоритм, который имеет некоторое начальное состояние, и он детерминистически детерминирует состояние в соответствии с сообщениями, полученными извне (т.е. Веб-клиентом).

Более правильно, Paxos следует рассматривать как распределенный журнал, вы можете прочитать об этом подробнее: Понимание Paxos - Часть 1

Ответ 3

Paxos используется для репликации репозиториев Subversion на основе WAN и высокой доступности Hadoop NameNode для компании, в которой я работаю (WANdisco plc.)

Ответ 4

Пример реального мира:

Cassandra использует Paxos, чтобы гарантировать, что клиенты, подключенные к различным узлам кластера, могут безопасно выполнять операции записи, добавляя "IF NOT EXISTS" для записи операций. Cassandra не имеет master node, поэтому две конфликтующие операции могут выдаваться одновременно на нескольких узлах. При использовании синтаксиса if-not-exist алгоритм paxos использует операции ордера между машинами, чтобы обеспечить только одно успешное выполнение. Затем эти клиенты могут использоваться клиентами для хранить достоверные данные с лимитом аренды. Пока большинство узлов Cassandra работают, это сработает. Поэтому, если вы определяете коэффициент репликации вашего пространства ключей равным 3, тогда 1 node может выйти из строя, из 5 затем 2 может выйти из строя и т.д.

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

Покер и Паксос:

Как и другие ответы, покер по очереди основан на правилах. Если вы разрешаете один мастер и много реплик, мастер решает следующее действие. Пусть говорят, что пользователь сначала нажимает кнопку "проверить", а затем меняет свое мнение и щелкает "свернуть". Это противоречивые команды, только первые должны быть приняты. Браузер не должен позволять им нажимать вторую кнопку, чтобы отключить ее при нажатии первой кнопки. Поскольку деньги задействованы, главный сервер также должен обеспечивать соблюдение правил и разрешать только одно действие на игрока за ход. Проблема возникает, когда мастер падает во время игры. Какая реплика может стать мастером и как вы обеспечиваете, чтобы только одна реплика стала мастером?

Один из способов справиться с выбором нового мастера - использовать внешнюю сильную последовательную службу. Мы можем использовать Cassandra для создать аренду для мастера node. Реплики могут тайм-аут на хозяине и попытка взять в аренду. Поскольку Кассандра использует Паксос, она терпима к ошибкам; вы можете читать или обновлять аренду, даже если узлы Cassandra вылетают.

В приведенном выше примере мастер покера и реплики в конечном итоге согласуются. Мастер может послать пульс, чтобы реплики знали, что они все еще связаны с мастером. Это быстро, когда сообщения текут в одном направлении. Когда мастер падает, в репликах могут быть условия гонки, которые пытаются стать мастером. Использование Paxos в этой точке дает вам сильное постоянство, по результатам которого node теперь является мастером. Это требует дополнительных сообщений между узлами для обеспечения консенсусного результата одного ведущего.

Ответ 5

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

Лучшим примером может быть игра с одновременными движениями, такими как Jeopardy. Paxos в этой ситуации позволил бы всем серверам вместе решать, в какой последовательности произошла серия тесно связанных событий (таких как звуковые сигналы), чтобы все серверы пришли к одному и тому же выводу.