MySQL: как обеспечить целостность в множественной архитектуре только для чтения

Question

Сценарий прост в описании, но может иметь сложный ответ:

Представьте себе случай, когда у вас есть только одна база данных mysql для записи. Тогда у вас есть около 5 или 6 баз данных только для чтения. База данных записи имеет счет для определенного инвентаря. У вас есть сотни тысяч пользователей, которые бьются об этом конкретном предмете, но их количество ограничено. Ради аргумента, скажем, 10 пунктов.

Каков наилучший способ продажи только 10 предметов? Если между моментом обновления ведомых только для чтения ведомых есть даже 200 мс, не может ли целостность подсчета устареть, таким образом, продавая инвентарь, которого у вас нет?

Как бы вы решили / масштабировали эту проблему?

Answer 1

Базовое решение для одновременных пользователей, вероятно, также охватит это. В какой-то момент транзакции «купить» вам нужно уменьшить инвентарь (на сервере записи). С помощью любого метода, убедитесь, что инвентарь не может опуститься ниже нуля.

Если останется один предмет и два человека попытаются его купить, одному не повезет.

Задержка репликации - это то же самое. Два пользователя видят продукт доступным, но к тому времени, когда они пытаются его купить, его уже нет. Хорошее решение для этого сценария охватывает как задержку репликации, так и пользователя, просто вырывающего последний элемент из-под другого пользователя.

Answer 2

Все зависит от того, когда и в каком окне вы решите заблокировать основную таблицу для обновления.

A. Если вы должны быть на 100% уверены, что предмет будет пытаться купить только тогда, когда он обязательно доступен. Вам нужно будет заблокировать предмет для конкретного пользователя, как только вы перечислите его ему (что означает, что вы временно уменьшите запас инвентаря)

B. Если у вас все в порядке с тем, чтобы показать сообщение «извините, у нас просто закончился запас». Вы должны заблокировать товар непосредственно перед выставлением счета (что ж, вы можете сделать это после завершения транзакции, но за счет очень разъяренного клиента)

Я бы выбрал подход А для блокировки и, возможно, пометил бы предупреждение "скоро будет распродан" для товаров с очень низким запасом. (если это очень частая ситуация, вы также можете подсчитать количество одновременных пользователей, попавших в предмет и дать более точное предупреждение)

С точки зрения бизнеса, вы бы не хотели, чтобы на складе было так мало (меньше, чем количество одновременных покупателей). Это, конечно, неизбежно в «рождественские» времена, когда нет ничего в наличии:) *