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