Знаете почему в розетке не ровно 230V, а 230V ±10%? И причем тут ваша база данн…

Сегодня расскажу про eventual consistency Начнём с электричества В розетке у вас может быть: 207V (230 - 10%) 230V (если повезло) 253V (230 + 10%) Может еще быть 198V (если старый стандарт от 220-10%) И это нормально. Система работает с погрешностью. Почему так? Потому что обеспечить ровно 230V во всех розетках одновременно, это технически сложно, дорого и не нужно (так как ваши приборы всё равно работают в этом диапазоне) А теперь про базы данных Представим, мы делаем социальную сеть и у нас распределенная база данных, в разных регионах. Вдруг пользователь из России обновил аватарку и она изменилась в базе данных в Москве. Что происходит: Москва: аватарка обновилась мгновенно Лондон: аватарка обновится через 100ms Токио: аватарка обновится через 200ms В какой-то момент времени в системе существуют разные версии аватарки. Пользователи из России могут увидеть новую аватарку, пользователи из Японии и Европы, пока еще видят старую. Через некоторое время все реплики синхронизируются, и аватарка везде станет одинаковая. Это и есть Eventual Consistency или по русски "в конечном итоге согласованность". Strong Consistency VS Eventual Consistency Strong Consistency (это строгая согласованность): Когда все видят одни и те же данные всегда Как например ровно 230V в розетке (идеал, которого не существует) Это медленно (так как нужно ждать синхронизации всех узлов) И это дорого (так как это сложная координация) Eventual Consistency (в конечном итоге согласованность): Разные узлы могут видеть разные данные временно Как в примере с 230V ±10% (диапазон, в котором всё работает) Это быстро (потому что мы не ждём синхронизации) И что важнее, это дёшево (так как меньше координации между узлами) CAP теорема

В распределённой системе можно выбрать только 2 из 3: C (Consistency) - согласованность Все видят одни и те же данные A (Availability) - доступность Система всегда отвечает на запросы P (Partition tolerance) - устойчивость к разделению Работает, даже если связь между узлами пропала

Однако на практике P (partition tolerance) нельзя выбрать, потому что сеть всегда может упасть, поэтому P обязательна. Получается мы выбираем между: C+P: согласованность важнее A+P: доступность важнее Когда Eventual Consistency - это нормально - Соцсети (лайки, комментарии) Увидели лайк на 2s позже? Ничего страшного - Статистика и метрики Счётчик просмотров не в реал-тайм? Не критично - Рекомендации и лента Чуть старая лента новостей? Тоже норм - DNS Обновление DNS записи распространяется часами, и это тоже ок Когда же нужна Strong Consistency - Банковские транзакции Нельзя списать деньги дважды - Бронирование билетов Нельзя продать одно место двум людям - Инвентарь товаров на маркетплейсе Нельзя продать то, чего нет на складе Поэтому 230V ±10% - это eventual consistency в физическом мире. Система не пытается держать ровно 230V везде и всегда, потому что это: Дорого Сложно Не нужно Вместо этого система гарантирует диапазон, в котором всё работает нормально. Так же и с распределёнными системами.

Вывод: Eventual consistency - это не баг, а фича. Не нужно пытаться сделать всё strongly consistent. Задайте себе вопрос: -"Что будет, если пользователь увидит данные с задержкой?" Если ответ "ничего страшного", то используйте eventual consistency Если ответ "катастрофа", то используйте strong consistency. Но будьте готовы платить И еще важный поинт: "Не все данные одинаково важны." Розетка это понимает и ваша архитектура тоже должна

8/100 Telegram