Что описывает eventual consistency?
- Что такое согласованность в конечном счёте?
- Почему после записи можно прочитать старое значение?
Если записи прекратятся, все реплики со временем придут к одному значению. Сразу после записи разные клиенты могут видеть разное.
- Цена за доступность и масштабируемость: запись подтверждается без ожидания всех реплик
- Типичное окно — миллисекунды, но под нагрузкой бывает секунды и больше
- Поверх добавляют гарантии: read-your-writes, монотонное чтение, причинная согласованность
А ещё Недопустима там, где важен инвариант: остаток денег, уникальность, бронирование последнего места
Подробно
Суть. Запись принимается одной репликой (или частью) и распространяется на остальные асинхронно. Пока она не дошла, чтение с другой реплики вернёт старое значение. Гарантия только одна — сходимость при отсутствии новых записей. Сколько ждать, не гарантируется.
Зачем. Не ждать подтверждения всех реплик — значит быстрее отвечать и продолжать работу при отказе части узлов и при разделении сети (AP в CAP). Так работают асинхронные реплики баз, DNS, кэши, CDN, Cassandra и DynamoDB по умолчанию, поисковые индексы и проекции в CQRS.
Аномалии, которые видит пользователь:
- сохранил — обновил страницу — не видит изменения;
- комментарий появился и пропал при следующем запросе (попал на отстающую реплику);
- ответ виден раньше вопроса.
Как жить: выбрать нужные гарантии сессии — читать свои изменения с лидера (read-your-writes), привязывать пользователя к реплике (монотонное чтение), показывать результат записи из ответа без перечитывания; для конфликтующих одновременных записей — версии, «последний побеждает» или CRDT.
Где нельзя: операции с инвариантами — списание денег, остатки, уникальные логины, бронирования. Там нужна сильная согласованность в одной точке: транзакция в лидере, условная запись, консенсус.
Что хотят услышать
- Определение через сходимость и отсутствие гарантии времени.
- Почему её выбирают: доступность и задержка.
- Видимые аномалии и гарантии сессии, которые их закрывают.
- Где eventual consistency недопустима.
Частые ошибки
- Считать, что задержка всегда миллисекунды и её можно не учитывать.
- Применять её к деньгам и остаткам.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Все реплики согласованы мгновенно, но запись подтверждается клиенту с задержкой
- ✗Данные между репликами в итоге так никогда и не приходят к согласию
- ✗Запись возможна только в одну реплику, а остальные доступны лишь для чтения
- ✓Реплики сходятся к одному состоянию спустя время после записи
Что спросят дальше
- Что такое read-your-writes consistency?
- Когда eventual consistency недопустима?
Разбор темы
- CAP и согласованность
Точная формулировка CAP и типичные искажения, неизбежность разделения и выбор C/A по операции, спектр согласованности и сессионные гарантии, кворумы N/R/W и их пределы, PACELC и разрешение конфликтов.
Связанные вопросы
- Какие промежуточные гарантии находятся между строгой и итоговой согласованностью? Middle
- Пользователь публикует комментарий и должен сразу видеть его в ленте, а остальным допустима задержка в несколько секунд. Какие гарантии согласованности вы заложите и как это реализуете? Middle
- Пользователь сохранил изменения, обновил страницу — а изменений нет. Что происходит и как это исправить? Middle
- Какие бывают схемы репликации и чем они отличаются? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.