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