В этом посте мы поговорим о самом часто используемом паттерне проектирования базы данных.
Этот паттерн подразумевает что все команды на создание и изменение данных, отправляются в первичную (ведущую) БД, а операции чтения отправляются ведомым БД. По статистике запросов на чтение больше в 10 раз чем остальных запросов. Поэтому мы создаем большее кол-во ведомых БД.
1. Когда Алиса размещает заказ на ozon.ru, запрос отправляется в Службу заказов (Order service).
2. Служба заказов создает запись о заказе в первичной БД (write). Данные реплицируются в две ведомых БД.
3. Алиса просматривает детали заказа. Запрос отправляется ведомой БД (read).
4. Алиса просматривает недавнюю историю заказов. Запрос отправляется ведомой БД (read).
В этой конфигурации есть одна серьезная проблема: задержка репликации.
При определенных обстоятельствах (сбой сети, перегрузка сервера и т. д.) данные в ведомых БД могут отставать на секунды или даже минуты от первичной БД. В этом случае, если Алиса сразу после оформления заказа проверит статус заказа, она может вообще не увидеть заказ. Это приведёт Алису в замешательство. В этом случае нам нужна согласованность, «чтение после записи».
Возможные решения этой проблемы:
- Чувствительные к задержке запросы на чтение, отправляются в первичную БД.
- Запросы на чтение, которые следуют сразу за запросом на добавление/изменение, в течение некоторого времени направляются в первичную БД.
- Ведомая БД обычно предоставляет способ проверить, догоняет ли она первичную БД. Если данные актуальны, запрос отправляется к ней. В противном случае произойдет сбой запроса или его перенаправление к первичной БД.
