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