Оптимальное решение для большого количества запросов к одной таблице базы данных

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

Наша таблица products содержит увеличивающийся первичный ключ, начинающийся с нуля, который мы используем для отслеживания количества выделенных продуктов, т. е. пользователь резервирует продукт и получает 1, следующий пользователь получает 2 и т. д.

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

Так как нам нужно гарантировать, что каждому покупателю выделяется только один продукт, и отслеживать, сколько продуктов было выделено, мы используем блокировку строк для каждого клиента, обращающегося к системе, чтобы гарантировать, что он записывает в таблицу до того, как следующий клиент нажмет система, т. е. обеспечение соблюдения правила «первым пришел — первым обслужен».

Мы обеспокоены узким местом, а именно временем обработки каждого запроса, поступающего в SQL Server 2008 Enterprise Edition, и блокировкой строк.

Мы не можем использовать несколько серверов, так как нам нужно обеспечить целостность первичного ключа, поэтому все, что требует репликации, не будет работать.

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

Еще немного информации:
Рассматриваемая таблица по существу содержит только два поля — ID и CustomerID. Решение заключается в бесплатной раздаче миллиона продуктов — отсюда ожидание высокого спроса и почему для нас имеет смысл использовать увеличивающийся первичный ключ в качестве ключа — как только ключ достигает миллиона, клиенты больше не могут регистрироваться. Кроме того, все продукты разные, поэтому важно правильно указать ключ, например. первые 100 зарегистрированных клиентов получают более ценный продукт, чем следующие 100 и т. д.

6
задан Brian Tompsett - 汤莱恩 24 March 2018 в 20:16
поделиться