Ответ
Eventual Consistency (согласованность в конечном счёте) — это модель согласованности, используемая в распределённых системах, которая гарантирует, что если в систему не поступает новых обновлений, то со временем все реплики данных придут к одному и тому же состоянию.
Простыми словами: система не обещает, что все узлы будут синхронизированы мгновенно, но гарантирует, что они в конечном итоге синхронизируются.
Контекст (Теорема CAP): Эта модель является компромиссом в рамках теоремы CAP (Consistency, Availability, Partition Tolerance). Системы с Eventual Consistency жертвуют строгой согласованностью (Consistency) ради высокой доступности (Availability) и устойчивости к разделению сети (Partition Tolerance).
Пример на Go: Представим обновление кэша пользователя на нескольких серверах. Основная база данных обновляется синхронно, а реплики кэша — асинхронно.
// Обновление данных с eventual consistency
func updateUserCache(userID string, data UserData) {
// Немедленно обновляем основное хранилище
db.Update(userID, data)
// Асинхронно и независимо обновляем реплики кэша
// Некоторое время кэш может быть неактуальным
go asyncUpdateReplica("replica1.cache.local", userID, data)
go asyncUpdateReplica("replica2.cache.local", userID, data)
}
Плюсы:
- Высокая доступность и низкая задержка: Запросы на запись могут быстро завершаться, не дожидаясь подтверждения от всех реплик.
- Отказоустойчивость: Система продолжает работать, даже если некоторые узлы временно недоступны.
Минусы:
- Чтение неактуальных данных (Stale Reads): Клиент может прочитать устаревшие данные с реплики, которая еще не получила последнее обновление.
Где используется: DNS, Cassandra, DynamoDB, Riak, системы кэширования.