我正在寻找一个简单的持久缓冲区作为 Java 应用程序中 JSON 消息的临时存储。内存使用应该是相对恒定的，并且不依赖于缓冲区中的消息数量。能够从过去的某个时间点重播消息会很高兴。删除旧消息应该是有效的。需要能够处理 1m 条消息/小时。
目前，我的应用程序使用本地 RabbitMQ 代理，它将消息铲到远程 RabbitMQ 代理。当远程代理关闭或不接受消息时，本地 RabbitMQ 代理的内存使用量会随着队列长度的增加而增加，最终它会停止接受消息。我想将其换成基于本地磁盘的缓冲区和将消息复制到远程 RabbitMQ 代理的线程。
有人有想法么？我看过 Kafka，但对于我的用例来说似乎有点过分了。MongoDB 是一种可能性，但我担心它的内存使用情况。
在任何系统中，内存使用始终是一个问题。我将 MongoDB 用于生产，当我与类似的解决方案（CouchDB、CouchBase、redis.io）进行比较时，MongoDB 在内存管理和易于实现方面非常出色。但我应该承认，我从来没有机会更详细地测试 Riak。
我正在存储 5.000.000 个用户记录，其中包含 4 个索引字段，所有用户会话都在一个使用消息服务的 rest/web 服务 api 后面。
我的消息服务使用同一服务器上的另一个数据库实例。我的用户记录至少有 20 个字段，会话记录只有 5 个字段。即使在繁重的加载过程中，我的 ubuntu 服务器也从未使用超过 10 GB 的内存。
希望这有助于弄清楚。
ps：一切都取决于数据模型以及您如何实现基础架构。
问候，
编辑：
我认为这是一个关于使用 MongoDB 进行消息传递的好幻灯片。
还有一篇关于 MongoDB 和消息传递的好文章。
您可以使用测试代码并查看结果是否适合您的解决方案。如果您进行测试，请不要忘记分享您的结果。