Eventual consistency — это модель распределённых систем, где обновления данных в конечном итоге распространяются на все узлы, а не синхронизируются сразу же. MongoDB достигает этого через архитектуру replica set, где один primary узел обрабатывает записи, а secondary узлы асинхронно реплицируют эти данные со временем.
readPreference: secondary, принимая потенциально устаревшие данныеMongoDB позволяет точно настраивать поведение консистентности:
writeConcern — определяет, сколько узлов должны подтвердить запись перед тем, как она считается успешнойreadConcern — контролирует свежесть данных, возвращаемых при чтенииwriteConcern: { w: "majority" } // более сильная консистентность
readConcern: { level: "majority" } // читаем только закоммиченные данные
| Приоритет | Компромисс |
|---|---|
| Высокая доступность | Принять eventual consistency, рискуя устаревшими чтениями |
| Сильная консистентность | Меньше доступности, выше задержка |
w: majority улучшает консистентность, но увеличивает latency записейMongoDB гибкая — она не навязывает единую модель консистентности. Разработчики выбирают нужный баланс между консистентностью, доступностью и производительностью исходя из требований приложения, используя настройки write и read concern.
Архитектура replica set в MongoDB гарантирует, что вторичные узлы получают подтверждение записи в точно тот же момент, что и первичный узел, благодаря синхронной репликации.
Новый — ещё не проверен сообществом
Вы