设置:
想象一个“类似推特”的服务，用户提交一个帖子，然后被许多(数百、数千或更多)用户阅读。

我的问题是关于构建缓存和数据库以优化快速访问和多次读取的最佳方式，但仍保留历史数据，以便用户(如果他们愿意)可以查看较旧的帖子。这里的假设是 90% 的用户只会对新内容感兴趣，并且偶尔会访问旧内容。这里的另一个假设是我们想要针对 90% 进行优化，如果较旧的 10% 需要更长的时间来检索，也可以。

考虑到这一点，我的研究似乎强烈指向使用缓存的方向 90%，然后还将帖子存储在另一个更长期的持久系统中。所以到目前为止我的想法是使用 Redis 作为缓存。优点是 Redis 速度非常快，而且它内置了 pub/sub，非常适合向多人发布帖子。然后我正在考虑使用 MongoDB 作为更永久的数据存储来存储相同的帖子，这些帖子将在 Redis 过期时被访问。

问题:
1. 这个架构能站得住脚吗？有一个更好的方法吗？
2. 关于在 Redis 和 MongoDB 中存储帖子的机制，我正在考虑让应用程序执行 2 次写入:第一次 - 写入 Redis，然后立即可供订阅者使用。 2nd - 成功存储到 Redis 后，立即写入 MongoDB。这是最好的方法吗？我应该让 Redis 将过期的帖子推送到 MongoDB 本身吗？想过这个，但是找不到太多直接从Redis推送到MongoDB的资料。

最佳答案

将 Redis 和 MongoDB 联系起来实际上是明智的:它们是优秀的团队成员。您可以在此处找到更多信息:

MongoDB with redis

一个关键点是您需要的弹性级别。 Redis 和 MongoDB 都可以配置为实现可接受的弹性级别，这些注意事项应在设计时讨论。此外，它可能会限制部署选项:如果您想要 Redis 和 MongoDB 的主/从复制，您至少需要 4 个盒子(Redis 和 MongoDB 不应部署在同一台机器上)。

现在，保留 Redis 用于队列、发布/订阅等可能会更简单一些……并且仅将用户数据存储在 MongoDB 中。基本原理是您不必为具有不同范例的两个商店设计相似的数据访问路径(这项工作的困难部分)。此外，MongoDB 具有内置的水平可扩展性(副本集、自动分片等)，而 Redis 仅具有自己动手的可扩展性。

关于第二个问题，写信给两家商店是最简单的方法。没有将 Redis 事件复制到 MongoDB 的内置功能。不过，设计一个监听 Redis 队列(将发布事件)并写入 MongoDB 的守护进程并不难。

https://stackoverflow.com/questions/11218941/