Как вы относитесь к возможной несогласованности при использовании Amazon RDS с помощью Read Replica?

Question

Рассмотрите корзину пользователя и заказ: клиент может выполнить действие addItemToCart, которое будет обрабатываться главным экземпляром базы данных. Тем не менее, действие getUserCartItems может быть выполнено на Read Replica, и оно может не содержать результат первого действия, однако из-за Replica Lag. Даже если мы попытаемся свести к минимуму это отставание, все-таки можно ударить по этому делу, так что мне интересно, какие решения вы пробовали на производстве?

Согласно @Henrik answer, у нас есть 3 варианта:

1. Wait at user till consistent. 

Это означает, что нам нужно выполнить опрос (регулярно или долго опроса) на стороне клиента и ждать, пока Replica получит обновление. Тем не менее, я полагаю, что Replica Lag не должна быть длиннее 1-5 секунд. Кроме того, чем меньше Replica Lag, тем больше производительность у нас будет.

2. Ensure consistency through 2PC. 

Если я правильно понял, мы должны объединить обе addItemToCart вставки и getUserCartItems выбрать в один агрегированный операции на внутреннем интерфейсе и вернуть getUserCartItems в ответ addItemToCart. Тем не менее, следующий запрос может по-прежнему не получать обновленную информацию из-за задержки ... Да, он возвращает немедленное подтверждение об успешной работе, и приложение может продолжить, однако при переходе к проверке требуются элементы корзины пользователей, чтобы правильно показывать цену, поэтому мы не фиксируем проблема в любом случае.

3. Fool the client. 

Приложение хранит/кэширует все данные успешно и использует их для показа. Да, это решение, но это, безусловно, требует дополнительного бизнес-логики, которые будут реализованы:

Perform getUserCartItems request; 

if (getUserCartItems returned success) 
    Store addItemToCart in local storage; 
else 
    Show error and retry; 

Perform getUserCartItems request; 

if (getUserCartItems contains addItemToCart ID) 
    Update local storage/cache and proceed with it. 
else  
    Use existing data from local storage; 

Как вы имеете дело с возможной противоречивости?

Answer 1

Правильный ответ состоит в том, чтобы НЕ отправлять запросы SELECT к считываемому ведомому, если данные должны быть немедленно доступны.

Вы должны структурировать свое приложение таким образом, чтобы все запросы в реальном времени попадали вашему хозяину, а все остальные запросы попали в один из ваших прочитанных подчиненных.

Для тех случаев, когда вам не нужны результаты в реальном времени, вы можете хорошо обмануть пользователя, используя что-то вроде запросов или веб-сайтов AJAX (веб-узлы сделают ваше приложение намного более удобным для использования, так как вас не будет забивая ваши серверы с многочисленными запросами AJAX).