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