Раздел 13. Геораспределение и доступность

Пользователи мессенджера разбросаны по всему миру, а сервер — это конкретные машины в конкретном месте. Если все машины в одном месте, у далёких пользователей всё тормозит, а одна авария способна положить сервис целиком. Этот раздел — про то, как разносить систему по планете и как она держится, когда отказывает что-то крупное.

Зачем несколько дата-центров

Дата-центр — это, по сути, здание, набитое серверами. Держать всё в одном дата-центре плохо по двум причинам: далёким пользователям медленно, и любая крупная авария там роняет весь сервис. Поэтому строят несколько дата-центров в разных регионах мира — и это решает обе проблемы сразу.

Близость и задержка

Почему расстояние вообще важно? Есть жёсткий физический предел: сигнал не может лететь быстрее скорости света. Чем дальше дата-центр, тем дольше каждое сообщение идёт туда и обратно. Пользователь в Азии, а дата-центр в США — и каждое сообщение делает долгий кругосветный крюк, ощутимо подтормаживая.

Решение: пользователь подключается к ближайшему дата-центру, и задержка резко падает. Это та же идея близости, что и в CDN из Раздела 9 — только там приближали файлы, а здесь приближаем соединения и саму логику.

Репликация между регионами

Чтобы пользователь в любой точке мира мог читать данные локально (а значит — быстро), и чтобы пережить потерю целого дата-центра, данные реплицируют между регионами — то есть держат их копии в разных дата-центрах. Репликацию мы уже встречали в Разделе 8; здесь копии разнесены не по соседним серверам, а по разным концам света.

И тут вылезает неизбежная сложность: копировать через океан медленно — мешает та же скорость света. Поэтому копия в удалённом регионе всегда чуть-чуть отстаёт от оригинала. Идеальной синхронности между континентами не бывает.

Главный компромисс: доступность против консистентности

Самое важное и самое «интервьюшное» место раздела. Представим, что связь между двумя регионами пропала или один регион упал. Тогда приходится выбирать:

• либо ждать согласования между регионами (строгая консистентность) — но при разрыве это означает, что сервис встаёт и недоступен;
• либо отвечать из локальной копии (доступность) — но эта копия может быть слегка устаревшей.

Мессенджер, как мы решили ещё в Разделе 2, склоняется к доступности: лучше работать на чуть устаревших данных, чем встать. Порядок и статусы сойдутся чуть позже (та самая «допустимая неточность»).

Но повторю важную оговорку из Раздела 6: это касается консистентности порядка и состояния, а не сохранности. Durability сообщения по-прежнему свята — само сообщение должно быть надёжно записано в нескольких копиях до того, как мы скажем «отправлено».

Как это обычно устроено

Несколько практических приёмов:

• Домашний регион. Данные пользователя или чата «приписывают» к региону, ближайшему к основным участникам; туда идут записи, а копии расходятся в другие регионы. Удалённый читатель видит сообщение с небольшой задержкой репликации — и это сознательно принятая цена.
• Геомаршрутизация. Пользователя направляют в его регион ещё на входе (на уровне адресов и точек входа, как в Разделе 12).

Потеря целого дата-центра

Что происходит при настоящей аварии — отказе целого дата-центра:

• Переключение на запасной (это называют failover): трафик уходит в другой регион, где есть копии данных.
• Пользователи упавшего региона переподключаются туда (их соединения рвутся — это обычный реконнект из Раздела 12).
• История и очереди не теряются, потому что они реплицированы — берутся из копий в живых регионах.
• Цена: может потеряться самый последний «хвост» записей, не успевших скопироваться. Именно поэтому критичное подтверждают только после репликации в несколько мест.
• Для тех, кого перекинули в более далёкий регион, возможна повышенная задержка — система продолжает работать, пусть и чуть медленнее (корректная деградация из Раздела 12).

Аналогия на финал: дата-центры — как склады сети магазинов в разных городах. Берёшь товар с ближайшего (быстро). Если один склад сгорел — заказы обслуживают с других, потому что товар заранее продублирован. Чуть дальше везти, но сеть работает.

Вопросы интервьюера (с разбором)

«Как снизить задержку для пользователей по всему миру?» Образец: «Несколькими дата-центрами в разных регионах: пользователя направляю в ближайший, чтобы сигнал не делал кругосветный крюк — расстояние упирается в скорость света. Данные реплицирую в регионы, чтобы читать можно было локально. Это та же идея близости, что и в CDN, но для соединений и логики.»

«Что реплицируем между регионами?» Образец: «Копии данных — историю сообщений, очереди — чтобы в каждом регионе можно было читать локально и чтобы пережить потерю целого дата-центра. Платим за это тем, что удалённая копия всегда чуть отстаёт: репликация через большие расстояния не мгновенна.»

«Как система ведёт себя при потере целого дата-центра?» Образец: «Срабатывает переключение на другой регион, где лежат копии данных, и пользователи переподключаются туда. История и очереди не теряются, так как реплицированы. Может пропасть лишь самый последний незареплицированный хвост, поэтому критичное подтверждаю только после репликации в несколько мест. Часть пользователей получит повышенную задержку, но сервис продолжит работать.»

---

#мессенджер #геораспределение #дата-центры #репликация-между-регионами #доступность #подготовка-к-интервью