Почему Paxos требуется для выборов лидера в cassandra

Я читал о протоколе распределенного консенсуса и наткнулся на Paxos. В нем говорится, что вам нужен Paxos для выборов лидера. Статья утверждает то же самое. Итак, мой вопрос: когда Cassandra является кольцевой архитектурой, а не master-slave, зачем ей нужен механизм выбора лидера. Более того, если ответ положительный, какова роль лидера в кольце Кассандры. Когда для связи в ринге используется протокол Gossip.


cassandra paxos gossip leader
person Naresh    schedule 30.07.2018    source источник
comment
Он описывает, как мы можем использовать Cassandra для выбора лидера (избегая смотрителя зоопарка). В продемонстрированном примере используется LWT, который внутренне использует Paxos.   -  person Praneeth Gudumasu    schedule 30.07.2018

Ответы (2)


arrow_upward
2
arrow_downward

В статье продемонстрирован пример реализации алгоритма выбора лидера с использованием функции Cassandra под названием Легкая транзакция. Дело не в выборе главного узла для Cassandra.

person Praneeth Gudumasu    schedule 30.07.2018

arrow_upward
1
arrow_downward

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

Рассмотрим следующий пример: система управляет деньгами пользователей. Допустим, один пользователь хочет внести 100$ на счет.

Текущий баланс (0$) + новые деньги (100$) = 100$.

Другой пользователь хочет обновить ту же учетную запись. Он вводит 20$ на этот счет. Его расчет происходит до того, как первый человек вставит свои деньги.

Текущий баланс (0$) + новые деньги (20$) = 20$.

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

Выбор лидера позволяет узлам синхронизировать свои обновления на одном ресурсе, чтобы убедиться, что каждое вычисление изолировано. «Я обновлю значение, если оно равно 0$». Выбор делается так, чтобы один узел мог координировать транзакцию для конкретного запроса.

В нашем примере 100$ будет обновлено, но 20$ не удастся, и пользователю нужно будет повторить попытку.

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

Дополнительные сведения по этой теме можно найти здесь.

person JayK    schedule 31.07.2018