设置：
想象一下'twitter like'服务，用户提交帖子，然后被许多（数百，数千或更多）用户阅读。
我的问题是关于构建缓存的最佳方法＆amp;数据库优化快速访问＆amp;许多读取，但仍保留历史数据，以便用户可以（如果他们想要）查看较旧的帖子。这里的假设是，90％的用户只对新内容感兴趣，并且偶尔会访问旧内容。这里的另一个假设是我们想要优化90％，如果旧的10％需要更长的时间来检索它，那就没问题了。
考虑到这一点，我的研究似乎强烈指出了为90％使用缓存的方向，然后还将帖子存储在另一个长期持久系统中。所以到目前为止我的想法是使用Redis作为缓存。优点是Redis非常快，而且它内置了pub / sub，非常适合发布给很多人的帖子。然后我考虑使用MongoDB作为一个更永久的数据存储来存储相同的帖子，这些帖子将在Redis过期时被访问。
问题：
这个架构有水吗？有一个更好的方法吗？
2.关于Redis＆amp; amp; MongoDB，我正在考虑让应用程序执行2次写入：第1次 - 写入Redis，然后立即可供订阅者使用。第二个 - 成功存储到Redis后，立即写入MongoDB。这是最好的方法吗？我应该让Redis将过期的帖子推送到MongoDB本身吗？我想到了这一点，但我找不到太多关于直接从Redis推送到MongoDB的信息。
答案 0 :(得分：36)
将Redis和MongoDB联系起来实际上是明智的：他们是优秀的团队成员。您可以在此处找到更多信息：
一个关键点是您需要的弹性级别。可以将Redis和MongoDB配置为达到可接受的弹性级别，并且应该在设计时讨论这些注意事项。此外，它可能会对部署选项施加约束：如果您想要Redis和MongoDB的主/从复制，则至少需要4个框（Redis和MongoDB不应部署在同一台机器上）。
现在，将Redis用于排队，发布/订阅等等可能会更简单一点......并且仅将用户数据存储在MongoDB中。理由是，您不必为具有不同范例的两家商店设计类似的数据访问路径（这项工作的难点）。此外，MongoDB具有内置的水平可伸缩性（副本集，自动分片等），而Redis只具有自己动手的可扩展性。
关于第二个问题，写两个商店将是最简单的方法。没有内置功能可以将Redis活动复制到MongoDB。设计一个监听Redis队列的守护进程（活动将被发布）并写入MongoDB并不是那么难。