У меня возник один вопрос, когда я читал Raft paper. Сценарий соблюдается. Есть 3 недавно запущенных инстанса Raft: R1, R2, R3. R1 выбирается лидером с nextIndex {1, 1, 1}, matchIndex {0, 0, 0} и термином 1. Теперь он получает команду 1 от клиента, и журналы экземпляров выглядят следующим образом:
R1: [index 0, command 0], [index 1, command 1]
R2: [index 0, command 0]
R3: [index 0, command 0]
Что делать, если сеть ненадежна? Если R1 отправляет этот журнал на R2, но время ожидания RPC AppendEntries истекло, лидер R1 должен повторно отправить [индекс 1, команда 1]. Затем он может дважды получать ответы {срок: 1, успех: истина}.
В документе говорится:
If last log index ≥ nextIndex for a follower: send AppendEntries RPC with log entries starting at nextIndex
• If successful: update nextIndex and matchIndex for follower (§5.3)
• If AppendEntries fails because of log inconsistency: decrement nextIndex and retry (§5.3)
Таким образом, лидер R1 увеличивает nextIndex и matchIndex дважды: nextIndex {1, 3, 1}, matchIndex {0, 2, 0}, что неверно. Когда лидер отправляет следующий RPC AppendEntries, то есть контрольное сообщение или репликацию журнала, он может исправить nextIndex, но matchIndex никогда не будет исправлен.
Мое решение - добавить порядковый номер как к аргументам AppendEntries, так и к результатам для каждого отдельного вызова RPC. Однако мне было интересно, есть ли способ решить эту проблему только с аргументами, приведенными в статье, то есть без порядкового номера.
Любой совет будет оценен и благодарим вас заранее.
