Как raft обрабатывает фиксацию записей из предыдущего?

Прочтите подпись к этому изображению. И (d), и (e) являются возможными разрешениями состояния журнала, созданного с помощью (a), (b) и (c). Проблема в том, что даже несмотря на то, что в (c) запись (2, 2) была реплицирована на большую часть кластера, это показывает, что она все еще может быть перезаписана, когда S5 выбран в (d). Итак, решение состоит в том, чтобы разрешить узлам фиксировать записи только из своего собственного термина. Другими словами, репликация записи на большинстве узлов не равных обязательств. В (c) запись (2, 2) реплицируется на большую часть кластера, но поскольку она не входит в термин лидера (по крайней мере, 4), она не фиксируется. Но в (e), после того, как лидер копирует запись из своего текущего термина (4), это предотвращает возникновение ситуации в (d), поскольку S5 больше не может быть избран лидером.

После того, как S1 воспроизведет запись 4 с более высоким сроком, чем 2 и 3. S5 больше не будет избираться лидером, поскольку стратегия выбора лидера Raft:

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

Итак, на мой взгляд, добавленная запись журнала 4 в (e) неявно продвигает термин всех записей перед ней. Потому что нас интересует только термин или последняя запись, а не запись 2.

Это похоже на то, что делает предлагающий в Фазе 2 Paxos:

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

То есть предложите изученное значение 2 с более высоким числом предложения.

Я думаю, что обе ситуации на рис. 8 (d) и (e) допустимы в Raft, потому что в документе говорится:

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

На рисунке 8 (d) записи с термином 2 отсутствуют в локальном журнале лидера S5, и они не фиксируются в конечном автомате. Допускается перезапись их записями с термином 3. Только записи в текущем журнале лидера могут считаться зафиксированными при подсчете количества реплик.

Если мы разрешим фиксировать запись из предыдущего термина, после (c) будет зафиксирована запись с номером 2. После этого, если 3 выбран в качестве лидера, он перезапишет зафиксированный 2. Таким образом, S5 и S1 будут выполнять разные команды. Чтобы предотвратить это, мы не допустим 2 совершенных. Таким образом, команды, которые выполняются во всех конечных автоматах, станут согласованными.

Я думаю, что вопрос в том, что лидер потерпел крах после того, как несколько последователей применили журнал к конечному автомату. В (c) на рисунке лидер скопировал журнал термина 2 более чем на половину узлов, а затем лидер обновляет commitIndex до 2 и отправляет тактовый сигнал. И до сбоя лидера только S2 получил контрольный сигнал и применяет журнал термина 2 к конечному автомату. Согласно документу, S5 может стать новым лидером голосами S3 и S4 и попытаться добавить журнал термина 3 к S2. ~ S4. Но эта операция не должна быть разрешена, потому что S2 уже применил журнал с индексом 2 к конечному автомату. Кажется, Raft не покрывает эту ситуацию.