Тим, ты действительно должен был опубликовать свой вопрос отдельно, а не как ответ на ФП, чего не было.
Но чтобы ответить, во-первых, прочитайте слайды Бена Блэка по адресу http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication-and-consistency.
Готово? Хорошо, теперь по конкретным вопросам:
«Как различия в состоянии данных [реплики] будут согласованы при последующем чтении?»
Победит самая высокая отметка времени.
«Все ли зоны работают от одних и тех же системных часов?»
Метки времени предоставляются клиентами (т. Е. Сервером приложений). Они должны быть синхронизированы, например, с ntpd (что в любом случае является хорошей практикой), но высокая точность не требуется, потому что, если порядок имеет значение, следует избегать конфликтов либо с помощью уникальных имен столбцов, либо с помощью внешней блокировки.
Например: если у вас есть список пользователей, следующих за вами в клоне Twitter, вы должны предоставить каждому подписчику свой собственный столбец, и не будет никакого способа потерять данные, независимо от того, насколько не синхронизированы часы.
Если у вас есть инструмент администратора для вашего сайта и два администратора загружают новый значок «одновременно», одно обновление выиграет, и не имеет значения, какое именно. Здесь вы хотите, чтобы ваши часы были синхронизированы, но «в течение нескольких мс» достаточно близко.
Если вы управляете регистрацией пользователей и хотите разрешить создание учетной записи «jbellis», только если она еще не существует, вам нужен менеджер блокировок, независимо от того, насколько синхронизированы ваши часы.
«Вернутся ли устаревшие данные?»
Узел (о котором лучше думать, чем о "зоне") не будет иметь данных, которые он пропустил во время простоя, до тех пор, пока он не отправит эти данные путем восстановления чтения, хинтованной передачи обслуживания или восстановления антиэнтропии. Тем временем он ответит на запросы на чтение устаревшими данными; если вы используете достаточно высокий уровень запросов на чтение уровня согласованности, то вы будете ждать достаточно других ответов, чтобы в любом случае всегда видеть самую последнюю версию, что может означать невозможность выполнить запросы, если недостаточно других реплик.
В противном случае низкий уровень согласованности (например, ОДИН) неявно означает «Я понимаю, что более высокая доступность и меньшая задержка, которую я получаю с этим более низким уровнем согласованности, означает, что я в порядке, если временно вижу устаревшие данные после простоя».