ken*_*nyc 5 database messaging design-patterns ipc
更具体地说我的应用程序:共享数据主要是持久性数据,例如监视状态,配置 - 不超过几百个项目,并且经常更新和读取但不超过1或2Hz.这些进程在同一台机器上是彼此本地的.
编辑1:更多信息 - 期望进程轮询他们感兴趣的一组数据(即监视)大多数数据在程序的生命周期内是持久的,但是一些(例如配置)需要在之后恢复软件重启.数据仅由所有者更新(假设每个数据为一个所有者)进程数量也很小(不超过10个)
虽然使用数据库显然更加可靠和可扩展,但在我看来,当我使用数据库时,在使用应用程序时共享数据时,它总是有点过分或过于繁重.而消息传递与例如.JMS也有中间件部分,但它更轻量级,并且具有更自然或灵活的通信API.我认为实现事件通知和命令模式也更容易.
如果有人能给我一个例子,说明哪一种情况会比另一种情况更可取,那将是非常有帮助的.
例如,我知道我们可以更容易地使用数据库在进程之间共享持久数据,尽管它也可以通过跨进程分发和/或与某些XML文件一起存储来实现消息传递.
根据这里,http://en.wikipedia.org/wiki/Database-as-IPC和http://tripatlas.com/Database_as_an_IPC.它表示在用于代替消息传递时它是一种反模式,但它没有详细说明,例如.与消息传递相比,使用数据库的性能有多糟糕.
我已经通过几个问过类似问题的帖子,但我希望找到一个专注于设计理由的答案.但是从我到目前为止阅读的那些问题中我可以看到很多人确实使用数据库进行IPC(或者用数据库实现了消息队列)
谢谢!
小智 5
我曾经编写过一个在大约 20 台实验室计算机上运行的数据采集系统。机器之间的所有通信都是通过 MySQL 数据库上的小表进行的。这个方案效果很好，随着时间的推移和系统的扩展，一切都扩展得很好并且保持了非常灵敏的响应。添加功能和修复错误很容易。您可以轻松调试它，因为所有消息传递都很容易利用。
数据库为您所做的事情是，它提供了一种快速、调试良好的方法，可以在网络流量非常繁忙时保持并发性。MySQL 的某人花了很多时间让网络东西在高负载下正常工作，如果你使用 tcp/ip 套接字编写自己的系统，你将花费大量的时间和精力重新发明这些轮子。
另一个优点是，如果您无论如何都使用数据库进行实际数据存储，则无需向系统添加任何其他内容。您可以将可能的故障点降至最低。
因此，所有那些说通过数据库进行 IPC 不好的人并不总是正确的。