Репликация с несколькими ведущими узлами

Продолжим разбирать репликацию по 5-й главе кабанчика («Высоконагруженные приложения» Мартина Клепманна).

У репликации с одним лидером есть недостаток: все операции записи идут через один узел (лидер), поэтому если между пользователем и лидером пропала связь, то пользователь не сможет совершать операции записи.

Если мы разрешим принимать запросы на запись нескольким узлам, и каждый такой узел будет перенаправлять информацию об изменениях всем остальным узлам, то получим репликацию с несколькими ведущими узлами (multi-leader, master — master). При такой схеме каждый из лидеров одновременно является репликой для других лидеров.

Когда используют схему с несколькими лидерами:

🗓 Приложения с офлайн-клиентами. Например, календарь-планировщик, приложения типа Яндекс.Диск, OneDrive и др. В этом случае у каждого устройства есть своя локальная база данных, служащая лидером (она принимает запросы на запись). Любые выполняемые в офлайне изменения синхронизируются с сервером и остальными устройствами при следующем подключении к интернету.

🌐 Система, использующая несколько ЦОДов. Внутри каждого из ЦОДов используется обычная репликация типа «лидер — реплика». Лидер каждого ЦОДа реплицирует свои изменения лидерам в других ЦОДах. При этой схеме пользователь пишет в ближайший ЦОД, поэтому приложение для него работает быстрее. Репликация в другие ЦОДы выполняется асинхронно и на пользовательский опыт не влияет.

Правильно реализовать репликацию с несколькими лидерами непросто. Основная проблема — конфликты записи, которые возникают когда на разных лидерах одна и та же запись обновляется разными значениями.

Например, вы договорились о встрече семьей и внесли в общий календарь запись «Семейная встреча 12:00». Все увидели пуш и решили конкретизировать название. Брат изменил название на «Шашлык 12:00», а бабушка на «Копаем картошку 12:00». Возникает конфликт. Конечно, если эти изменения пошли через разные лидеры.

#кабанчик #сисдиз