Эталонная архитектура: multi-region / глобальная
Когда пользователи географически распределены или требуется устойчивость к региональной катастрофе, данные распределяются по нескольким регионам. Это дерево шаг за шагом проходит через локальность чтения (реплика для чтения в каждом регионе), топологию записи (single-leader vs multi-leader vs кворум), резидентность данных/соответствие требованиям (GDPR), разрешение конфликтов и компромиссы между RPO/RTO и задержкой. Основная истина: из-за законов физики низкая задержка, строгая согласованность и запись в нескольких регионах не могут быть полностью достигнуты одновременно; осознанный компромисс обязателен.
Зачем вам multi-region: локальность чтения, запись/устойчивость или соответствие требованиям?
Multi-region архитектура дорога и сложна; уточните мотивацию. Вам нужна низкая задержка чтения для удалённых пользователей, межрегиональная запись/устойчивость к катастрофам, или реальное требование — чтобы данные оставались в определённой стране (юридическая резидентность)?
- Быстрое чтение для удалённых пользователей; запись может оставаться в одном регионе
- Нужна межрегиональная запись / устойчивость к потере региона
- Данные по закону должны оставаться в определённой стране/регионе
Какой должна быть топология записи: single-leader, multi-leader или кворум?
Для межрегиональной записи ключевое решение — модель лидерства. Все записи идут в один регион (просто, согласованно, но удалённая запись медленная), каждый регион может писать (низкая задержка записи, но конфликты), или запись принимается при подтверждении большинства регионов (кворум: согласованно, но с дополнительной задержкой)?
- Один регион пишет, остальные читают (просто и согласованно)
- Каждый регион может писать локально (низкая задержка записи)
- Запись с подтверждением большинства; согласованность прежде всего
Рекомендация: реплика для чтения в каждом регионе (локальность чтения)
Запись остаётся в одном основном регионе, а в каждом регионе пользователей размещается реплика для чтения, получающая данные от него. Пользователи читают с ближайшей реплики, и задержка чтения снижается; поскольку запись по-прежнему идёт в один центр, модель согласованности остаётся простой.
Рекомендация: запись с одним лидером (single-leader)
Все записи идут в один регион-лидер; остальные регионы — реплики для чтения, асинхронно получающие данные от лидера. Это самая простая и наиболее строго согласованная модель; конфликтов нет, потому что точка записи одна. Цена — высокая задержка записи из удалённых регионов.
Рекомендация: запись с несколькими лидерами (multi-leader) + разрешение конфликтов
Поскольку каждый регион может писать локально, задержка записи низкая, и даже если один регион отрезан, остальные продолжают писать. Цена высока: два региона могут по-разному обновить одну и ту же запись, и вам нужно спроектировать разрешение конфликтов.
Рекомендация: запись на основе кворума (подтверждение большинства)
Запись принимается, когда её подтверждает большинство (кворум) регионов/реплик; если чтение тоже идёт к большинству, гарантируется последнее значение. Модель устойчива к потере региона и строго согласована; цена — задержка, пока каждая запись достигает большинства.
Рекомендация: резидентность данных / соответствие требованиям (GDPR)
Некоторые данные (персональные, медицинские, финансовые) по закону должны оставаться в пределах определённой страны/региона (например, GDPR). В этом случае архитектура проектируется не по принципу «копировать везде», а так, чтобы данные были географически закреплены.