我们正在开发一些应用程序，其中数据库的更新必须传播到其他应用程序，如果他们对其他系统感兴趣，则会将更改发送到其他系统。最初的计划是将这些更改通知存储在关系数据库表中，以便在生产者和消费者之间进行缓冲。缓冲表应该能够缓冲一周的更改通知（消费者停用一周）。这将达到200 GB（是的，GB而不是MB）。这是一个很大的数字，但我们有很多数据......
现在有人建议使用JMS来缓冲而不是关系数据库表，因为缓冲区在概念上是一个队列。现在的问题是JMS系统（我们使用ActiveMQ）是否可以在不降低性能的情况下缓冲那么多数据（例如200 GB）。我们根本没有经验可以知道。那里有人有线索吗？
答案 0 :(得分：2)
不幸的是，这似乎是除了你以外的任何人都无法回答的那种问题。在硬件，网络基础设施方面存在很大的差异，甚至你对“性能下降”可以容忍多少的定义，其他任何人的经验可能都不是直接适用的。
由于听起来你已经有了一个ActiveMQ实例，我建议你只创建一个新队列并开始向其中抛出数据（当然是在你的开发/测试环境中），看看会发生什么。自己做这个实验的努力很少（一些经纪人配置设置增加你的经纪人的限制加上一些代码来向经纪人发布消息），并且它更可能给你一个你可以信任的答案而不是别人的经验类似于不同的硬件，网络，ActiveMQ负载等。