44

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

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

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

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

4

1 回答 1

38

将 Redis 和 MongoDB 联系起来其实是明智的：他们是优秀的团队成员。您将在此处找到更多信息：

带有 redis 的 MongoDB

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

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

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

于 2012-06-27T10:02:19.120 回答