Обработка транзакций продажи, когда веб-приложение переходит в автономный режим

Question

Мое веб-приложение (Point of Sale) обрабатывает продажи в нескольких филиалах.Каждая продажа имеет уникальный целочисленный идентификатор.Некоторый идентификатор продажи в филиале 1 - n , затем следующая продажа в филиале 2 - n + 1.

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

Кошмар случается, когда две или более ветвей теряют интернет-соединение.Потому что, когда они совершают продажу в автономном режиме, и интернет снова включается, сервер получит две продажи с одним и тем же идентификатором, что ужасно, потому что билет клиента уже распечатан!

Мой план сейчас состоит в том, чтобы сделатькаждый идентификатор продажи представляет собой сочетание идентификатора филиала и фактического номера продажи этого филиала.Таким образом, ID продажи филиала 1 будет 1-1 , а следующая продажа из филиала 2 будет 2-1 .Звучит хорошо, пока у браха нет двух точек продаж, что не так, но это не очень надежно для будущего.

Какой, по вашему мнению, лучший подход?Есть ли лучший способ сделать это?

Answer 1

В идеале, каждая торговая точка имеет свой идентификатор.Например, я работал в международной розничной сети (не буду называть ее здесь), которая имела тысячи филиалов по всему миру и до 15 точек продаж в каждом филиале.Каждому POS был присвоен собственный идентификатор, и он использовал этот идентификатор при аутентификации во внутренней системе.

Если это так в вашей настройке, то вместо идентификатора филиала вы должны использовать POSЯ БЫ.Таким образом, если у вас есть несколько POS в одной ветви, вы предварительно ожидаете POS ID к ID транзакции.

Answer 2

Единственный действительно безопасный способ избежать коллизий идентификаторов для одного идентификатора - сервер всегда назначает идентификаторы. Если POS переходит в автономный режим, вам может потребоваться выделить локальные и временные идентификаторы для локальной регистрации продажи, а затем, когда POS возвращается в оперативный режим, вы получаете реальные идентификаторы с сервера и изменяете локальные идентификаторы на реальные идентификаторы перед отправкой транзакций. , Однажды у меня была система, которая использовала отрицательные числа для обозначения созданных клиентом идентификаторов и положительные числа для идентификаторов, создаваемых сервером. Когда сервер получит отрицательный идентификатор, он изменит его на уникально созданный идентификатор сервера и вернет этот идентификатор клиенту, чтобы клиент мог обновить свою базу данных, указав реальный идентификатор транзакции.

Если вы хотите / нуждаетесь в идентификаторах, определенных клиентом, которые являются глобально уникальными, то каждому клиенту POS требуется назначенный сервером уникальный идентификатор, который может быть частью составного идентификатора, состоящего из нескольких частей. Затем каждый клиент может просто поддерживать свой счетчик, который в сочетании с уникальным идентификатором клиента всегда является глобально уникальным идентификатором. Это расширение вашей концепции BranchID, за исключением того, что это clientID, который уникально назначается каждому клиенту, поэтому вы можете иметь несколько клиентов POS в каждом филиале. Назначение clientID может быть выполнено вручную во время настройки клиента или более динамично, запрашивая у сервера уникальный clientID во время процесса установки или инициализации.

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

Answer 3

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