Рекомендации по архитектуре приложений для торговых точек

Мне нужно разработать приложение для торговой точки, которое будет использоваться в нескольких местах. В каждом месте будет использоваться одна база данных, а в другом месте будет основная база данных со всеми перемещениями денежных средств и запасов. Ограничение заключается в том, что доступное интернет-соединение между узлами очень плохое, поэтому определенным образом все местоположения большую часть времени будут работать в автономном режиме, то есть без подключения к Интернету, и, когда соединение будет снова доступно, будут повторно синхронизироваться с главная база данных.

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

какой будет правильный подход в этой схеме?

Планирую использовать dotnet и MSSql Server 2k8

С Уважением


person Sebastian Marcet    schedule 16.03.2010    source источник
comment
Связано только в заголовке: stackoverflow.com/questions/2448769   -  person Henk Holterman    schedule 16.03.2010
comment
@Henk: Плохая ссылка - по этой ссылке нет ответов, кроме умного комментария !!!!   -  person t0mm13b    schedule 16.03.2010
comment
Требуется ли для других db полная база данных или только ее части?   -  person Dean J    schedule 16.03.2010
comment
@tommie: это все еще связано, я не сказал дубликат.   -  person Henk Holterman    schedule 16.03.2010
comment
@Henk: честно ... но по этой ссылке нет ответов, чтобы несправедливо назвать ее дубликатом ...   -  person t0mm13b    schedule 16.03.2010


Ответы (4)


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

При построении архитектуры следует учитывать несколько моментов:

  • есть ли ограничения на то, как ваше приложение может рассинхронизироваться? Например. если ваше приложение не подключалось к мастеру в течение месяца, должно ли оно работать без сбоев? Вы должны разрешить соответствующие возможности хранения на клиенте и способы эскалации проблемы при достижении порогового значения.

  • Вы неизбежно столкнетесь с конфликтами. Например. когда вы принимаете заказ, он может оставаться на клиенте в течение 4 часов, а когда он, наконец, достигает сервера, заказанный продукт может даже не существовать. Проявите творческий подход к тому, что может пойти не так, и определите, как эти дела должны разрешаться.

  • Убедитесь, что у вас есть приличное ведение журнала, особенно для вещей, которые пересекают соединение. Вы должны легко найти информацию журнала на сервере и клиенте, которая относится к одной и той же бизнес-транзакции.

  • Убедитесь, что вы можете протестировать свои компоненты без других.

  • И, конечно же, в распределенной системе вы должны знать, насколько надежен клиент. Т.е. как вы можете утверждать, что сообщение, исходящее от сервера или клиента, действительно исходит от клиента, а не подделано кем-то или чем-то еще.

  • Четко определите доступную пропускную способность, чтобы убедиться, что все необходимые данные действительно умещаются. Многие небольшие транзакции могут помочь, поскольку они с меньшей вероятностью будут прерваны из-за прерывания соединения.

Вы также можете найти эта книга полезна

person Jens Schauder    schedule 16.03.2010
comment
+1 Хороший ответ! У меня есть связанный с этим вопрос: заголовок stackoverflow.com/questions/2586199/ - person Jonas; 06.04.2010

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

Безопасность, очевидно, будет внедряться как-то с нуля. Подумайте об этом - подход к созданию базы данных в каждом месте - НЕТ-НЕТ. Поскольку a) Stock Control - если фондовый контроль будет локализован, очень высока вероятность того, что с ним может произойти какая-то скрипка, чтобы «искусственно» раздуть маржа прибыли / убытка по сделкам продажи. б) Бывают ситуации, когда цена продукта может быть одной или обеими, один и тот же штрих-код или разные штрих-коды, несмотря на идентичную упаковку - это может произойти довольно легко - вы сканируете что-то, вы клянетесь, что это в системе, и в конечном итоге тратите часы, пытаясь выяснить это, пока штрих-код не будет изменен. c) Продукт может иметь тот же штрих-код, но цена изменится в соответствии с рыночными условиями - это может привести к погоне за дикими гусями, пытающимися решить, следует ли увеличьте существующий запас до новой цены или подождите, пока старый запас не иссякнет, затем внесите изменение цены.

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

Таким образом, именно здесь безопасность должна вмешаться с нуля, крайне важно, чтобы вы действовали очень осторожно и правильно спроектировали это, поскольку неправильно спроектированный POS (даже если он действительно работает) может привести к тому, что кассиры будут возиться с уровнями запасов, прибылью / loss, возьмите наличные из POS ... Кроме того, как будет обеспечиваться безопасность в отношении потока наличных, поступающих из POS ... подумайте об этом ... там может возникнуть скрипка ... в обход Система POS полностью и положить деньги в карман ...

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

Безопасность также должна быть рассмотрена в случае «У меня заблокирована база данных - хорошо и хорошо», но что касается передачи данных, ее можно легко перехватить ... что бы вы ни говорили, там БУДЕТ всегда будьте технически подкованным оператором, работающим с POS ... Если проблема возникает в самой POS-системе, есть вероятность, что оператор «посоветуется» с внешними людьми, чтобы исправить это, как они, вероятно, будут чувствовать » Я не хочу беспокоить команду поддержки - им, наверное, надоело, что я приставал к ним », - это подчеркивает и резюмирует ряд вещей:

  1. Безопасность с нуля
  2. Обучение должно строго контролироваться, исходя из здравого смысла.
  3. Если сомневаетесь, спросите пожилых людей ... некоторые на самом деле не утруждают себя этим и предполагают, что операторы знают, что делают ...
  4. Необходимость устранения человеческих ошибок и условий, которые находятся вне контроля POS, рыночных колебаний цен на продукты, ошибок штрих-кода.
  5. И последнее, но не менее важное: проектируйте пользовательский интерфейс так, чтобы он был как можно более простым и дружелюбным, без каких-либо разочарований, таких как отказ принимать вводимые данные и т. Д., Вы получите дрейф ...
person t0mm13b    schedule 16.03.2010

Возможно, вы захотите посмотреть на IBM Retail Integration Framework и IBM WebSphere Remote Server как на комплект программного обеспечения. В основном он использует очередь сообщений для синхронизации .... с локальными базами данных и сервером приложений в магазине. Вот что делают Walmart, Target, Kroger ... все.

person Albert T. Wong    schedule 13.07.2010

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

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

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

person Bernd    schedule 16.03.2010