Репликация и шардирование

Ключи и узлы хешируются на одно кольцо; ключ принадлежит первому узлу по часовой стрелке. При добавлении или удалении узла переезжает только ~1/N ключей, а не почти все, как при hash % N.

Лидером может стать только узел, за которого проголосовало большинство. Два большинства всегда пересекаются, поэтому в одном «сроке» (term) не бывает двух лидеров — это защищает от split brain.

Запись ушла в лидера, а чтение — на асинхронную реплику, которая ещё не догнала. Это нормальное поведение асинхронной репликации; приложение должно давать нужные гарантии само.

Горячий ключ не делится ни хешем, ни consistent hashing: все запросы к нему идут в один узел. Нужно размножить ключ для чтения или разбить его для записи.

С одним лидером — все записи через лидера, реплики повторяют его журнал. С несколькими лидерами — запись в любом дата-центре, конфликты разрешаются потом. Без лидера — клиент пишет и читает сразу в несколько реплик по кворуму.

Переносить данные по частям, пока система работает: копия + догоняющий поток изменений + переключение маршрутизации по одной части и проверка.

Шардирование делит данные между узлами по ключу шардирования. Ключ выбирают так, чтобы частые запросы шли в один шард, а нагрузка распределялась равномерно.

Синхронная — лидер подтверждает запись, когда реплика её сохранила: потерь при падении лидера нет, но задержка записи растёт, а отказ реплики может остановить запись. Асинхронная — подтверждает сразу: быстро, но последние записи могут потеряться.