Чем active-active репликация принципиально отличается от active-passive при отказе площадки?
В active-active несколько площадок одновременно принимают трафик, поэтому отказ одной из них обычно переносится без запуска отдельного резервного узла, но система должна разрешать конфликты между конкурентными изменениями. В active-passive запись выполняется через активную площадку, а резервная в основном ждёт переключения; это упрощает согласованность, но добавляет задержку failover и риск потери последних асинхронно реплицированных данных.
Подход active-passive появился как относительно простой способ повысить доступность: одна система обслуживает запросы, другая поддерживает копию и принимает нагрузку после отказа первой. Такой дизайн уменьшает число одновременно изменяющих состояние участников и тем самым упрощает репликацию.
Active-active стал востребован, когда одного резервного центра было недостаточно для требований к глобальной доступности, задержке и использованию вычислительных ресурсов. Он позволяет обслуживать пользователей из ближайшей площадки и не держать резервные ресурсы без нагрузки, но переносит часть сложности отказоустойчивости в модель данных и маршрутизацию.
При отказе площадки нужно сохранить доступность сервиса, целостность данных и предсказуемое поведение уже выполнявшихся операций. Нельзя считать, что наличие двух копий автоматически означает отсутствие потерь: важны направление записи, подтверждение репликации, момент переключения и возможность расхождения состояний.
В active-passive опасность возникает при переключении на резервную площадку. Если репликация асинхронная, резерв может не содержать подтверждённые клиенту последние записи; если обе площадки временно считают себя активными, возникает split-brain.
В active-active главная проблема иная: две площадки могут одновременно изменить один объект или связанные объекты. Простое правило вроде Last Write Wins может скрыто удалить корректное изменение, а независимое принятие записи не гарантирует глобального порядка операций.
В active-passive обычно существует один логический владелец записи. Резервная площадка получает изменения, но не обслуживает обычные записи до переключения. При отказе выполняются обнаружение отказа, выбор новой активной площадки, предотвращение записи старого владельца и перенаправление трафика.
Если репликация синхронная, подтверждение записи означает, что требуемые площадки уже сохранили данные; это уменьшает риск потери при failover, но повышает задержку и может сделать запись недоступной при проблемах связи. Асинхронная репликация быстрее и доступнее, однако допускает окно потери данных и требует явно определить допустимый RPO.
В active-active обе площадки принимают операции. Для безопасной работы нужны детерминированная маршрутизация владельца данных, разрешение конфликтов, идемпотентность операций и, при необходимости, координация через кворум или консенсус. Для разных типов данных подходят разные стратегии: выбор победителя, слияние версий, CRDT, бизнес-компенсация или запрет конкурентной записи одного ключа.
Ни один из вариантов не даёт одновременно максимальную доступность, минимальную задержку и строгую глобальную согласованность при сетевом разделении. Active-active не является автоматически более отказоустойчивым: при конфликтной модели данных его восстановление и проверка корректности могут быть существенно сложнее. Active-passive проще контролировать, но требует надёжного механизма failover и готовности принять его задержку или возможную потерю данных.
Платформа заказов работает в двух регионах. Пользователи должны продолжать оформлять заказы при потере одного региона, а изменения статуса заказа не должны приводить к двум одновременно подтверждённым платежам.
Вариант active-active для всего заказа даёт лучшую доступность и меньшую задержку, но создаёт конфликт при одновременном изменении оплаты или отмены в разных регионах. Разрешение конфликта по времени записи опасно: более поздняя запись может быть технически новее, но бизнес-событие уже необратимо выполнилось.
Вариант active-passive для платёжного агрегата проще: один регион владеет операциями списания, а второй становится владельцем только после контролируемого failover. Минус — переключение может занять время, а при асинхронной репликации нужно учитывать возможное окно потери.
Практичное решение — использовать active-active для чтения и независимых операций, но назначить одного владельца записи для платёжного агрегата в каждый момент времени. Переключение владельца защищается fencing-механизмом, а платёжные команды имеют идемпотентные идентификаторы. Это сохраняет доступность большей части системы и не допускает двойного выполнения критической операции; цена решения — сложность маршрутизации и ограничение записи во время смены владельца.
Нет. Это правило выбирает одну версию по техническому признаку, например по времени или счётчику, но не понимает смысл изменения. При конкурентном обновлении разных полей оно может потерять одно из корректных изменений, а при несинхронизированных часах порядок может быть определён неверно. LWW допустим только тогда, когда потеря проигравшей версии приемлема или данные дополнительно сохраняются для разрешения конфликта.
При потере связи резервная площадка может ошибочно решить, что активная недоступна, и начать принимать записи, тогда как старая площадка продолжает работать. Возникают два владельца одного состояния. Нужны fencing старого владельца, внешний арбитр или другой механизм, гарантирующий, что только одна площадка имеет право выполнять записи; одного DNS-переключения или тайм-аута недостаточно.
Это определяется не числом реплик, а семантикой подтверждения и задержкой репликации. При асинхронной репликации существует lag между активной и резервной площадками, поэтому подтверждённые клиенту операции могут отсутствовать на резерве. Этот интервал задаёт фактический RPO; уменьшить его можно синхронным подтверждением, более частой репликацией или журналированием, но обычно ценой задержки, пропускной способности или доступности.