我想实现一个分布式销售点系统，有点像中描述的系统销售点应用程序架构建议 https://stackoverflow.com/questions/2454629/point-of-sale-app-architecture-advice.
它是一个具有以下特征的分布式系统：
- 客户是关键任务，即使网络连接或服务器出现故障，它们也应该可以工作，但只能持续几天左右。
- 客户端必须易于安装。
- 每个客户端都有自己的本地嵌入式数据库。
- 客户端和服务器之间的通信使用消息队列。
- 服务器用于备份、记账、统计以及向客户分发价格。
- 服务器放置在互联网上。
我正在使用 JavaDB 作为数据库在 Java Swing 中实现客户端。
我的应用程序应如何与消息代理和数据库通信？
我以前从未使用过消息队列和消息代理。我的想法是应用程序从数据库读取，但写入消息代理，消息代理写入数据库并与服务器通信。或者这是一个坏主意？我应该如何解决这个问题？
因此，除了我的嵌入式数据库之外，我还需要找到一个消息代理，最好是一个用 Java 编写的、可以嵌入到我的应用程序中的消息代理，以便于安装。
从纯粹的技术层面来看，这可能是一个很好的起点：http://java.sun.com/products/jms/tutorial/ http://java.sun.com/products/jms/tutorial/
您还绝对应该获得一本“企业集成模式”一书，它解释了使用排队系统的所有各种方式。
根据您的描述，我认为以下模式是有用的（抱歉，不知道书中使用的术语，因为我现在没有。自己编造）：
发布订阅：服务器将发布消息（例如价格信息的更新），该消息将传递给订阅此类信息的所有客户端。您必须讨论的一个重要情况是这样一个问题：当您的客户端在此类广播期间断开连接时会发生什么。您必须确保它不会错过任何消息，或者有办法再次赶上。
即发即忘：一个通信伙伴（例如客户）将发送一条消息，而不期望任何类型的响应。排队系统将负责最终的交付。这可用于提交订单等。
回电：这就像两个或多个相反方向的即发即忘消息。后续调用将有一个 id，以便将消息标记为对之前收到的特定消息的响应。当您提交订单但需要某种答复时，这很有用。当然，答案可能会在一天后到达，因此您需要一个未完成订单的列表，该列表可能也应该对用户可见，或者在列表支持人员中可见。发送多个回复时，您必须处理消息不按顺序到达的情况。如果可能的话，处理此问题的一个好方法是在每个后续消息中包含早期消息的所有信息。这样您就可以简单地丢弃旧消息。
所以沟通可以这样进行：
- 服务器偶尔会向所有客户端发送更新。该消息可能应该包含某种版本信息，以便客户端可以确保他们拥有所有消息。
- 定期（或在一段时间内没有从服务器收到更新后或...）客户端请求服务器进行特殊更新，以确保其拥有所有当前信息。上面提到的版本信息可以用来识别缺失的信息
- 客户端接收消息并将内容存储在本地数据库中
- 客户端从数据库读取数据以向用户呈现信息
- 客户端向服务器提交订单或其他内容，可能会收到不同步的答案
一些一般建议：
通过排队，您将陷入并发地狱。因此，要对所有可能出现“错误”的事情发挥创意。例子是
- 消息到达时无序
- 发送时接收器不可用（这就是首先使用消息传递的原因）
- 接收器不可用并且永远不会重新上线。消息传递服务器具有保证传递的选项。这意味着他们必须存储消息，直到实际发送为止。如果客户端永远不会重新上线，消息将永远保留，填满存储空间
确保所有消息处理与应用程序的其余部分完全分离，以便于测试。
仔细考虑升级服务器和客户端的过程，尤其是当消息格式发生变化时。您要么必须在同一时间点进行所有升级，中间有一些停机时间，要么您的服务器必须能够在一段时间内处理新旧消息格式。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
