Я пытался реализовать простой один главный узел против системы с несколькими резервными узлами, чтобы узнать о распределенной и отказоустойчивой архитектуре.
На данный момент моя система выглядит так:
N разных узлов, каждый из которых одинаков. 1 главный узел с простым веб-сервером.
Все узлы взаимодействуют друг с другом, используя простой протокол сердцебиения, и каждый поддерживает глобальное состояние (количество доступных узлов, кто является мастером, время простоя и время работы друг друга).
Если какой-либо узел не получает извещения от ведущего в течение заданного времени, он поднимает тревогу. Если достигается консенсус, что ведущий не работает, избирается новый ведущий.
Если сеть узлов разделяется.
- And the master is in minor partition, then it will stop serving request and go down by itself after a set period of time. Minor group cannot elect master (some minimum nodes require to make decision)
- Новый мастер выбирается в основном разделе по истечении установленного времени после отсутствия ответа от старого мастера.
Теперь я столкнулся с проблемой, то есть на шаге 4 выше есть временной разрыв, когда старый мастер все еще обслуживает запросы, а новый мастер избирается на основном узле.
Кажется, это может привести к несогласованности данных в системе, если какой-то клиент решит записать новые данные в старый мастер. Как мы избегаем этой проблемы. Буду рад, если кто-то укажет мне правильное направление.
