В raft, когда узел перезагружается, он пытается повторить все записи журнала, чтобы догнать состояние. Но если узел снова выйдет из строя на этапе восстановления, узел выполнит какую-то операцию дважды. Эти дважды повторные операции нарушат конечный автомат, если операции не являются идемпотентными.
Согласно приведенному выше описанию, мой вопрос заключается в том, нужно ли на практике делать операции идемпотентными в системе, использующей raft?
По моему опыту, Raft, Paxos и их друзья используются для реализации распределенных конечных автоматов и баз данных (которые является распределенным конечным автоматом). При рассмотрении в этом контексте вы действительно, действительно, действительно хотите, чтобы записи были идемпотентными; иначе ваши конечные автоматы рано или поздно разойдутся.
Вам нужна идемпотентность, даже если вы использовали неупорядоченные очереди, такие как rabbit-mq или ActiveMQ, потому что их гарантии в лучшем случае по крайней мере один раз.
Конечно, ничто не помешает использовать неидемпотентные записи. За исключением, возможно, обзора дизайна. Короче говоря, я не могу представить себе ни одного сценария, в котором очередь лучше обслуживалась бы неидемпотентными записями. Не один.
Нет, не требуется, чтобы записи журнала были идемпотентными, если вы используете алгоритм распределенного консенсуса, такой как Paxos или Raft. Создание системы на основе идемпотентных операций дает много преимуществ, но это не всегда возможно. Алгоритмы распределенного консенсуса отлично подходят для случаев, когда вы не можете достичь идемпотентности, поэтому вам нужно быть уверенным, что операции обрабатываются не более одного раза на каждой реплике. Более того, они позволяют гарантировать, что операции всегда выполняются в одном и том же порядке на каждой реплике. Это очень сильные свойства, и вам нужно выполнить некоторую относительно дорогостоящую координацию, чтобы гарантировать, что они сохраняются, поэтому мы стараемся избегать их, где это возможно.
Распределенный консенсус гарантирует, что каждая запись журнала будет одинаковой для каждой реплики, если эта запись журнала будет принята большинством реплик. Каждая реплика должна обрабатывать только те записи журнала, которые были приняты большинством реплик, поскольку другие записи журнала могут измениться во время восстановления. Каждая реплика должна тщательно отслеживать, какие операции она уже обработала, чтобы избежать их повторной обработки во время восстановления. Это легко сделать, поскольку журнал полностью упорядочен, поэтому каждая реплика может отслеживать операции, которые она обработала, с помощью одного числа, представляющего позицию последней обработанной операции в журнале.
Фактически, другой взгляд на распределенный консенсус заключается в том, что это эффективный способ добавить идемпотентность (и коммутативность) обратно в набор операций, которые могут не быть идемпотентными (или коммутативными). Так что нет, операции не обязательно должны быть идемпотентными, потому что вместо этого вы можете получить необходимую идемпотентность из алгоритма распределенного консенсуса.
Да, они должны быть недемпотентными и детерминированными в том смысле, что выполнение операции над ведомым устройством должно переводить ведомое устройство в то же состояние, что и ведущее устройство.
Эта средняя операция не может считывать внешнее состояние (время настенных часов, генератор случайных чисел), но может использовать только текущее значение конечного автомата и данные из записи журнала, чтобы выбрать следующее значение конечного автомата.
Но из-за структуры протокола raft он обеспечивает семантику максимум однократной доставки, поэтому невозможно выполнить одну операцию или записать ее в журнал репликации несколько раз. Вам не нужно проверять, что эта операция уже была выполнена, как в системе, которая обеспечивает семантику по крайней мере один раз.
