Разберите последствие: почему read repair не превращает асинхронную репликацию в строго согласованную?
Read repair исправляет обнаруженное расхождение только после чтения и не гарантирует, что все последующие чтения сразу увидят одинаковое значение. Между чтением и завершением исправления реплики могут продолжать возвращать устаревшие данные, а конкурентная запись может сделать выбранное для исправления значение уже неактуальным.
Read repair появился как практический механизм для систем с асинхронной репликацией и моделью eventual consistency. Такие системы предпочитают доступность и продолжение работы при сетевых сбоях, поэтому реплики могут временно расходиться.
Полное синхронное подтверждение каждой записи от нужного числа реплик увеличивает задержку и снижает доступность. Read repair позволяет постепенно сближать реплики во время обычных чтений, не оплачивая стоимость синхронной репликации для каждой операции.
Предположим, чтение обращается к нескольким репликам и получает значения разных версий. Система выбирает наиболее новую версию и отправляет устаревшим репликам исправление.
До завершения этого исправления другая операция чтения может попасть на старую реплику и получить прежнее значение. Если в этот момент произошла новая запись или исправление доставляется с задержкой, простое обновление может даже затереть более новую версию, если система неправильно обрабатывает версии.
Поэтому read repair уменьшает время расхождения, но сам по себе не обеспечивает линеаризуемость, глобальное отсутствие устаревших чтений или мгновенное выравнивание всех реплик.
При чтении система обычно собирает ответы реплик, сравнивает их версии и определяет победившее значение по версии, логическому времени или другому правилу разрешения конфликтов. Затем она отправляет устаревшим репликам исправление — синхронно в рамках текущего запроса или асинхронно после ответа клиенту.
Ключевое ограничение состоит в том, что исправление является отдельной операцией. Пока оно не применено на всех нужных репликах, состояние системы остаётся неоднородным. Даже после исправления новая запись может законно изменить значение, поэтому нельзя считать, что результат одного read repair навсегда установил единое состояние.
Надёжная реализация должна сравнивать версии, а не только значения. Реплика должна отклонять исправление с более старой версией; иначе запоздалый ответ или задержавшийся repair может откатить данные. При конкурентных записях система должна использовать причинные метаданные, версии или определённое правило разрешения конфликтов.
Read repair также не заменяет фоновой антиэнтропийной синхронизации. Если ключ редко читают, его устаревшая реплика может долго не встретиться с read repair. Фоновая сверка нужна для обнаружения и исправления таких расхождений независимо от пользовательского трафика.
Если требуется строгое чтение после записи, применяют другие гарантии: чтение с достаточным уровнем реплик, маршрутизацию к лидеру, версии чтения или протокол консенсуса. Их цена — дополнительные задержки, более сложное управление отказами и иногда потеря доступности при недоступности нужного большинства.
Сервис профилей хранит данные на трёх репликах. После изменения адреса чтение получает новый адрес от двух реплик и старый — от третьей; система запускает read repair для устаревшей реплики.
Вариант с одним read repair без проверки версий прост и дёшев, но опасен: задержавшаяся старая запись может позже затереть новый адрес. Вариант с синхронным обновлением всех реплик даёт более сильную гарантию, но повышает задержку и может блокировать запись при сетевом разделении.
Практичное решение — применять repair только вместе с монотонными версиями, отклонять более старые обновления и дополнить read repair фоновой антиэнтропийной сверкой. Для операций, которым нельзя возвращать устаревший профиль сразу после изменения, чтение направляют через механизм, гарантирующий необходимую версию, а read repair оставляют механизмом восстановления, а не источником строгой согласованности.
1. Может ли read repair гарантировать, что следующий запрос увидит исправленное значение?
Нет, если следующий запрос может обратиться к другой ещё не исправленной реплике. Такая гарантия появляется только при дополнительном механизме: маршрутизации к актуальному узлу, чтении с подходящим кворумом, передаче минимально допустимой версии или другой форме session consistency.
2. Почему исправление должно учитывать версию, а не только само значение?
Два одинаковых или разных значения могут соответствовать разным моментам записи. Без версии система не отличит актуальную запись от запоздалого сообщения и может применить устаревшее состояние поверх нового. Версионная проверка позволяет принимать только обновление, которое не старше уже сохранённого.
3. Чем read repair отличается от фоновой антиэнтропийной синхронизации?
Read repair запускается как следствие пользовательского чтения конкретного ключа и обычно исправляет только обнаруженные расхождения. Антиэнтропийная синхронизация работает независимо от чтений, периодически сравнивает наборы данных или их компактные представления и поэтому может найти проблемы в редко читаемых ключах. Эти механизмы дополняют друг друга, но ни один из них сам по себе не делает асинхронную репликацию строго согласованной.