消息/事件驱动基础设施的设计模式
我正在构建我的第一个系统，该系统出于扩展以外的原因严重依赖消息队列。长话短说，将有许多客户端通过互联网连接到中央服务器，每个客户端都能够编辑服务器上的数据，当发生此类事件时，其他客户端需要实时更新。
有谁知道涵盖此类场景的任何既定设计模式？
明显的工作流程是这样的：
用户编辑UI ->记录在数据库上编辑 ->消息被添加到队列->其他客户端更新
我对这个工作流程的唯一问题是，编辑记录的 UI 也将侦听消息，并且可能没有一些黑客行为，然后也进行不必要的自我更新。原则上这并没有什么问题，但我对 GUI 模式（我想这与消息传递模式类似）（例如 Martin Fowlers Passive View）的经验让我感觉这种方法可能不是最好的方法。
I'm building my first system that relies heavily on a message queue for reasons other than scaling. To cut a long story short there will be many clients connected to a central server via the internet, each client has the ability to edit data on the server, when such an event occurs the other clients need to be updated live.
Does anyone know of any established design patterns covering such scenarios?
The obvious work flow is this:
User edits UI -> record is edited on the db -> message is added to the queue -> other clients update
My only problem with this workflow is that the UI that edited the record will also be listening for the message and likely without some hackery also then unnecessarily update itself. Nothing wrong with this in principle, but my experience with GUI patterns (which I imagine will be similar to messaging patterns) such as Martin Fowlers Passive View give me a feeling that this type of approach may not be the best way to go.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种解决方案（这对您在其他方面有好处，例如日志记录/审核）是将客户端的ID（PID +主机名？）包含到记录中，然后监听广播消息的客户端可以轻松过滤掉“由客户端更新”的消息字段与自己的 ID 匹配。
这可能是也可能不是一种模式（如果是，我会很感激有人添加带有名称的评论/编辑），但它确实解决了您的问题。
One solution (which would benefit you in other ways, e.g. logging/auditing) is to include the client's ID (PID+hostname?) into the record, then clients listening to broadcast messages can easily filter out the messages whose "updated by client" field matches their own ID.
This may or may not be a pattern (if it is, I'd appreciate someone adding a comment/edit with the name), but it does solve your problem.
观察者模式似乎最适合您的问题。有时候GoF的书还是很好看的。 :)
http://en.wikipedia.org/wiki/Observer_pattern
The Observer Pattern would seem to fit your problem best. Sometimes the GoF book is still good to look at. :)
http://en.wikipedia.org/wiki/Observer_pattern