Запросы на очереди для каждого клиента

Question

Моя бэкэнд-система обслуживает около 10 тыс. POS-устройств, каждое устройство будет запрашивать обслуживание в последовательном стиле, однако мне интересно, как бэкэнд-гарантия обрабатывает запросы данного клиента в последовательном стиле.

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

Моя идея - установить постоянную очередь для каждого устройства (клиента), но нормально ли настроить очереди 10K? Я не уверен, пожалуйста, помогите.

Answer 1

Это невероятно сложная область информатики, и многие из этих проблем были решены много раз. Я бы не стал изобретать колесо.

Мой совет:

• читать и полностью понимать ACID (резюме перефразировать):
  • Атомарность - Если какая-либо часть транзакции не удается, вся сделка не удается, и база данных не ушел в неизвестном или поврежденном состоянии. Это hugely Важно. Положитесь на существующее программное обеспечение, чтобы это произошло в реальной базе данных. И не изобретайте структуры данных, которые требуют, чтобы вы изобрели свою собственную систему транзакций. Сделайте свои транзакции как можно меньше, чтобы уменьшить сбои.
  • Консистенция - База данных никогда не остается в недопустимом состоянии. Все операции, совершенные для него, перейдут в новое действующее состояние.
  • Изоляция - Операции, выполняемые вами в базе данных, могут выполняться одновременно и приводить к тому же состоянию, что и выполняются один за другим. ИЛИ безопасно выполнен внутри транзакции блокировки.
  • Прочность - После совершения сделки она останется такой.

И существующая система и ваша предложенная идея звучит как они потенциально могут нарушать ACID:

• запоминания состояния системы запроса, вероятно, нарушающей (или делают его трудно не нарушать) изоляции ,
• Очередь может нарушить долговечность, если не сделать пуленепробиваемым способом.

Не говоря уже о проблемах с масштабируемостью. Объедините масштабируемость и ACID, и у вас тяжелая ситуация требует серьезного опыта.

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