Здравствуйте, Slicer [Mirkwood], Вы писали:

C>>Я не очень понимаю зачем такое вообще нужно. Почему нельзя использовать обычную БД, если требуется read-after-write целостность?
SM>Разумный вопрос. Но он распадается на два, постараюсь кратко ответить.
SM>* Если "обычные" это полностью консистентные, то я отвечу так. Хотелось научиться применять eventual consistency решения, потому что в будущем, чувствуется, мне все чаще будут встречаться задачи такого рода
Я работаю с eventual consistency, но чисто по необходимости. Они требуют особой организации данных для того, чтобы можно было более-менее нормально этим пользоваться.

Я не пользовался ES, так что могу рассказать как я делал бы в случае абстрактного клиента в вакууме. В данном примере, я бы организовал данные так:
1) Каждый клиент получает непрозрачный "контекст соединения" — блоб данных в несколько сотен байт, кодирующий нужное состояние.
2) Этот контекст указывается при всех операциях, в которых важна read-after-write целостность.
3) Контекст является короткоживущим объектом, и каждая операция может вернуть новый контекст. Клиент обязан в этом случае для будущих операций использовать этот новый контекст.

Базу документов делим на shard'ы, привязывая определённые серверы к определённым shard'ам. Каждый shard внутри хранит монотонно увеличивающийся счётчик изменений. Соответственно, при операции записи возвращается контекст, который укажет на ожидаемые счётчики для затронутых shard'ов. При чтении эти значения будут использоваться для того, чтобы подтвердить, что реплика полностью обновилась до нужного уровня.