Рекомендации по архитектуре приложения в точках продаж - PullRequest
2 голосов
/ 16 марта 2010

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

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

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

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

Привет

Ответы [ 4 ]

4 голосов
/ 16 марта 2010

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

Несколько вещей, которые вы должны учитывать при построении вашей архитектуры:

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

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

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

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

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

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

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

2 голосов
/ 16 марта 2010

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

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

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

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

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

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

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

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

0 голосов
/ 17 марта 2010

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

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

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

...