При причинной согласованности могут ли разные реплики наблюдать конкурентные записи в разном порядке?
Да. Причинная согласованность требует сохранять порядок только между причинно связанными операциями, поэтому конкурентные записи разные реплики могут увидеть в разном порядке. Это допустимо, пока ни одна реплика не наблюдает следствие раньше породившего его события.
Подход появился как компромисс между строгой согласованностью и полностью асинхронной репликацией. В географически распределённых системах глобальная синхронизация каждого чтения и записи увеличивает задержку и снижает доступность при сетевых проблемах.
Причинная согласованность сохраняет важные зависимости между событиями, но не требует единого глобального порядка для независимых операций. Это позволяет уменьшить координацию, сохранив осмысленное поведение для пользователя.
Пусть пользователь сначала создал публикацию, а затем оставил к ней комментарий. Комментарий причинно зависит от публикации: если реплика показывает комментарий, она должна уже показывать и публикацию.
Одновременно два пользователя могут независимо изменить настройки или добавить сообщения. Если эти операции не зависят друг от друга, разные реплики вправе применить их в разной последовательности. Ошибка возникает не из-за самого различия порядка, а если система нарушает порядок причинной зависимости или необоснованно объявляет конкурентные версии одной победившей.
Система связывает операцию с уже наблюдёнными ею изменениями. При распространении записи реплика передаёт также информацию о зависимостях; принимающая сторона не должна сделать запись видимой раньше обязательных предшественников.
Для операций A и B, где B было выполнено после наблюдения результата A, требуется порядок A → B на каждой реплике, которая видит обе операции. Для независимых операций A и B такого требования нет: одна реплика может показать A, затем B, а другая — B, затем A.
Это слабее линеаризуемости, где все операции должны выглядеть так, будто произошли в едином порядке, согласованном с реальным временем. Причинная согласованность обычно даёт меньшую задержку и выше доступность, но приложение должно быть готово к разным порядкам конкурентных изменений.
Практическая реализация может использовать метаданные зависимостей, например версии реплик или векторные метки. Их задача — определить, какие записи уже должны быть видимы перед данной записью; конкретный формат метаданных зависит от протокола хранения.
Основные ограничения — рост служебных метаданных, задержка ожидания отсутствующих предшественников и необходимость определить политику конфликтов для конкурентных записей. Причинная согласованность сама по себе не выбирает победителя конфликта и не обеспечивает атомарность нескольких сервисных операций.
В региональной системе публикаций пользователь сначала создаёт пост, а затем отвечает на него. Реплика в другом регионе получает ответ раньше самого поста из-за разной задержки сетевых сообщений.
Вариант со строгой согласованностью устранил бы проблему за счёт глобального подтверждения, но увеличил бы задержку и мог бы блокировать записи при разделении сети. Полностью асинхронная репликация дала бы высокую доступность, однако позволила бы пользователям увидеть ответ без исходного поста.
Выбран вариант с причинной согласованностью: ответ публикуется с зависимостью от версии поста, а реплика задерживает его отображение до получения этой версии. Независимые посты реплики применяют в любом локально удобном порядке. В результате причинный сценарий остаётся корректным, а для конкурентных изменений сохраняется доступность без глобальной сериализации.
Нет. Единый порядок для конкурентных операций относится к более сильным гарантиям, например к тотальному порядку или линеаризуемости. Причинная согласованность требует одинакового порядка только там, где между операциями есть причинная связь.
Нет. Конкурентность определяется отсутствием причинного отношения, а не равенством или близостью показаний часов. Одна операция может быть причинно последующей даже при неточных часах, если клиент или протокол уже наблюдал результат первой.
Реплика не должна делать следствие видимым раньше предшественника. Она может отложить применение, поместить запись в буфер или вернуть временно неполный результат — в зависимости от модели чтения. Цена сохранения гарантии — дополнительная задержка и возможный рост буфера; если приложение не может ждать, оно должно явно обрабатывать состояние неполной видимости данных.