我需要开发一个将在多个地点使用的销售点应用程序。在每个位置，它将使用单个数据库，并且在另一个位置将是具有所有现金流和库存移动的主数据库。限制是节点之间可用的互联网连接非常差，因此在某种程度上所有位置大部分时间都将脱机工作，即没有互联网连接，并且当连接再次可用时，将重新同步主数据库。
我正在考虑开发一个在每个位置都有一个数据库的架构，并在主数据库和其他数据库之间实现复制，但当互联网连接在节点中脱机时，他们需要继续在离线模式下工作直到互联网连接将再次可用。我不确定复制是否是这种模式的正确方法，因为节点将插入和更新本地数据库，需要将现金流数据和库存数据传播到主数据库和其他节点。
这个架构中的正确方法是什么？
我计划使用dotnet和MSSql Server 2k8
此致
答案 0 :(得分：4)
我会考虑将排队系统作为本地数据库的替代方案。我希望这样的产品能够在连接可用时提供自动开始传输消息的功能。但这只是一个技术问题。
构建架构时应考虑的几件事情：
是否允许您的应用程序不同步？例如。当你的应用程序没有连接到主服务器一个月，仍然应该没有顺利运行？当达到阈值时，您必须允许客户端上的适当存储功能以及升级问题的方法。
你一定会遇到冲突。例如。当您接受订单时，它可能会在客户端上停留4个小时，当它最终到达服务器时，订购的产品可能甚至不再存在。对可能出错的内容进行创作，并定义如何解决这些案例。
确保您拥有不错的日志记录，特别是对于正在越过连接的内容。您应该能够轻松地在服务器和客户端上找到与同一业务事务相关的日志记录信息。
确保您可以在没有其他组件的情况下测试组件。
当然，在分布式系统中，您必须访问客户端的可信度。即你怎么能断言来自服务器或客户端的消息真的来自客户端而且不是由某人或其他人伪造的。
清楚地量化您可用的带宽量，这样您就可以确保所有必需的数据真正适合。许多小事务可能会有所帮助，因为它们不太可能因连接中断而中断。 / p>
您也可能会发现this book有用
答案 1 :(得分：2)
我可以在设计基础架构时与您分享一些提示，但首先您需要确定第一个也是重要的第一个因素 - 安全性，我将强调该方案以及我对它的体验。
安全性显然会以某种方式从头开始合并。想一想 - 在每个位置拥有数据库的方法是NO-NO。因为 a） 股票控制 - 如果股票控制将被本地化，那么很可能会出现这样的小提琴，以便'人为地'膨胀销售交易的利润/亏损边际。 b） 在某些情况下，产品的价格可能是或两者，条形码相同或条形码不同，尽管包装相同 - 这很容易发生 - 您扫描什么，你发誓它在系统中，并最终浪费时间试图找出它直到条形码被更改。 c） 该产品可以有相同的条形码，但价格会发生变化以反映市场情况 - 这可能会导致一场疯狂的追逐，试图弄清楚是否要将现有库存标记为新价格，或等到旧库存耗尽，然后进行价格变动。
这会带来一个如何处理这个问题和做什么的毛茸茸的情况 - 因此必须强制执行安全 - 不是通过计算机，而是通过人类，可能会发生简单的人为错误，例如接收外部产品相同的条形码，但价格增加/减少，并把它放在货架上...这可能会带来不便，并阻碍客户购买产品，转到柜台，扫描，支付现金的POS流量。你得到漂移。
因此，这是安全必须从头开始介入的地方，必须非常小心地设计并正确设计，因为设计不正确的POS（即使它确实有效）会导致收银员摆弄股票水平，盈利/亏损，从POS获取现金...此外，如何对来自POS的现金流量实施安全措施......想一想......那里可能会出现小提琴......通过完全绕过POS系统并将现金放入口袋......
如何同步到主系统，这将必须在工作时间之外完成，具体取决于提交的事务数量，此外，同步操作可能需要时间，因此在工作时间之外，没有任何意义它是在客户等待购买的那一天运行的。
在“我已经锁定数据库 - 好和好”的情况下还需要考虑安全性，但是数据的传输又很容易被拦截......不管你说什么，那里< strong> WILL 始终是操作POS的技术娴熟的操作员...如果POS系统本身出现问题，操作员可能会“咨询”外部人员修复它，因为他们可能我觉得'我不想麻烦支持团队 - 他们可能会厌恶我纠缠他们'，这强调并总结了许多事情：
答案 2 :(得分：1)
您可能希望将IBM的零售集成框架和IBM WebSphere Remote Server视为软件包。基本上它使用Message Queue进行同步....与商店中的本地数据库和应用服务器。这就是沃尔玛，塔吉特，克罗格......所有这些。
答案 3 :(得分：0)
您需要的是一个本地缓存，它与中央数据库异步同步。
您提议的本地数据库只是这种缓存的可能实现。还有其他选项，如消息队列，甚至可能是简单的文本文件。
使用原始数据库复制执行此操作会导致任何方法无法检查中央数据库中的任何内容。我宁愿建议在应用程序逻辑中构建同步功能。