如何使用 Message Broker 和数据库设计分布式应用程序? [英] How to design a distributed application using a Message Broker and a Database?

问题描述

我想实现一个分布式销售点系统，有点像 销售点应用架构建议.

I would like to implement an distributed Point-Of-Sale system, somewhat like the one described in Point of sale app architecture advice.

这是一个具有以下特点的分布式系统:

It is a distributed system with these charachteristics:

• 客户端是关键任务，即使网络连接或服务器出现故障，它们也应该可以工作，但只能持续几天左右.
• 客户端必须易于安装.
• 每个客户端都有自己的本地嵌入式数据库.
• 客户端和服务器之间的通信使用消息队列.
• 服务器用于备份、记账、统计和向客户分发价格.
• 服务器位于互联网上.

• The clients are mission critical, they should work even if the network connection or the server fails, but just for a few days or so.
• The clients must be easy to install.
• Each client has it's own local embedded database.
• The communication between the clients and the server is using a message queue.
• The server is used for backup, bookkeeping, statistics and distribute prices to the clients.
• The server is placed on internet.

我正在以 JavaDB 作为数据库在 Java Swing 中实现客户端.

I am implementing the client in Java Swing with JavaDB as the database.

我的应用程序应该如何与消息代理和数据库通信?

我以前从未使用过消息队列和消息代理.我的想法是应用程序从数据库读取，但写入消息代理，消息代理写入数据库并与服务器通信.或者这是一个坏主意?我应该如何解决这个问题?

I have never used Message Queues and Message Brokers before. My idea is that the application reads from the database, but writes to the message broker, and the message broker writes to the database and communicates with the server. Or is this a bad idea? How should I solve this?

所以除了我的嵌入式数据库之外，我还需要找到一个消息代理，最好是一个用 Java 编写的可以嵌入到我的应用程序中的消息代理，以便于安装.

So besides my embedded database, I need to find a message broker, preferably one written in Java that could be embedded in my application, for easy installation.

推荐答案

在纯技术层面上，这可能是一个很好的起点:http://java.sun.com/products/jms/tutorial/

On a pure technical level this might be a good point to start: http://java.sun.com/products/jms/tutorial/

您还绝对应该得到一本企业集成模式"一书，它解释了使用排队系统的所有各种方式.

You also should absolutely get a copy of the book "Enterprise Integration Patterns" It explains all the various ways one can use queuing systems.

根据您的描述，我认为以下模式很有用(抱歉，我不知道书中使用的术语，因为我现在没有.自己编写):

From what you describe, I envision the following patterns to be useful (sorry, don't know the terms used in the book, since I don't have it right now. Making up my own):

• publish subscribe:服务器将发布消息(例如价格信息的更新)，这些消息将传递给所有订阅此类信息的客户端.您必须解决的一个重要问题是，当您的客户端在此类广播期间断开连接时会发生什么.你必须确保它不会错过任何消息，或者有办法再次赶上.

• publish subscribe: The server would publish messages (e.g. updates to price information) which get delivered to all clients subscribing to that kind of information. One important case you'll have to cover is the question, what is going to happen, when your client is disconnected during such a broadcast. You have to make sure it doesn't miss any message, or has a way to catch up again.

即发即弃:一个通信伙伴(例如客户端)将发送一条消息，而不期待任何类型的响应.排队系统将负责最终交付.这可用于提交订单等.

fire and forget: One communication partner (e.g. the client) will sent a message, without expecting any kind of response. The queuing system will take care of eventual delivery. This could be used for submitting orders and the like.

回叫:这就像两个或多个相反方向的火和忘记消息.后续调用将有一个 id 以便将消息标记为对之前收到的某个消息的响应.当您提交订单但需要某种答案时，这很有用.当然，答案可能会在一天后到达，因此您需要一份未完成订单的列表，该列表可能也应该对用户可见，或者在列表支持人员中可见.在发送多个回复时，您必须处理消息无序到达的情况.如果可能，处理此问题的一个好方法是在每个后​​续消息中包含先前消息的所有信息.这样您就可以简单地丢弃旧邮件.

call back: This is like two or more fire and forget messages in opposite directions. Where subsequent calls will have an id in order to tag the message as a response to a certain message received before. This is usefull when you submit orders, but need some kind of answer. Of course the answer might arrive a day later, so you'll need a list of outstanding orders, which probably should also be visible to the user, or at list support personal. When sending multiple replies, you must handle the case of messages arriving out of order. When possible a nice way to handle this is to include all the information of earlier messages in each following message. This way you can simply discard older messages.

所以沟通可以这样进行:- 服务器偶尔会向所有客户端发送更新.该消息可能应该包含某种版本信息，以便客户端可以确保他们拥有所有消息.- 定期(或在一段时间内没有收到来自服务器的更新或......)客户端请求来自服务器的特殊更新，以确保它具有所有当前信息.上面提到的版本信息可以用来识别缺失的信息- 客户端接收消息并将内容存储在本地数据库中- 客户端从数据库读取以向用户呈现信息- 客户端向服务器提交订单或其他任何内容，可能会收到不同步的答复

So communication could work like this: - server occasionally sends updates to all clients. The message probably should contain some kind of version information, so the clients can make sure, they have all the messages. - on a regular basis (or aftger receiving no update from the server for some time or ...) the client requests a special update from the server in order to ensure that it has all the current information. The version information mentioned above can be used to identify the missing information - clients receive the message and store the content in the local db - client reads from db in order to present information to the user - client submits orders or what ever to the server, possibly receiving an out of sync answer

一些一般性建议:

通过排队，您正处于并发地狱之中.因此，对所有可能出错"的事情发挥创意.例子是- 无序到达的消息- 发送时接收器不可用(这是首先使用消息传递的原因)- 接收器不可用，永远不会回到网上.消息传递服务器具有保证传递的选项.这意味着他们必须存储消息，直到实际交付它.如果客户端永远不回来，消息将永远存在，填满存储空间

With queuing you are in the middle of concurrency hell. So get creative about all the things that can go 'wrong'. Examples are - messages arriving out of order - receiver not available at time of sending (well that is the reason for using messaging in the first place) - receiver not being available and never going back online. Messaging server have options to guarantee delivery. This means they have to store the message until the actually deliver it. If clients never come back online, messages will stay for ever, filling up the storage place

确保所有消息处理与应用程序的其余部分完全分开，以便于测试.

Make sure all the messaging handling is cleanly separated from the rest of your application for easy testing.

仔细考虑升级服务器和客户端的过程，尤其是当消息格式发生变化时.您要么必须在同一时间点进行升级，中间有一些停机时间，要么您的服务器必须能够在一段时间内处理新旧消息格式.

Think through the process of upgrading server and clients especially when the message formats change. You either have to upgrade all at the same point of time with some downtime in between, or your server must be able to process old and new message format for some time.

这篇关于如何使用 Message Broker 和数据库设计分布式应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！