Rediscaching和Mongo的持久性架构

设置:
想象一下,一个用户提交一个post,然后被许多(数百,数千或更多)用户阅读的“twitter like”服务。

我的问题是关于构buildcaching和数据库来优化快速访问和多次读取的最佳方法,但仍然保留历史数据,以便用户可以(如果他们想要的话)看到较旧的post。 这里的假设是,90%的用户只会对新东西感兴趣,并且偶尔会访问旧的东西。 另一个假设是我们想要优化90%,如果较老的10%需要一些时间才能恢复,那么就可以了。

考虑到这一点,我的研究似乎强调了90%使用caching的方向,然后将这些post存储在另一个更长期的持续系统中。 所以我的想法到目前为止是使用Redis的caching。 Redis的优点是速度非常快,而且它已经build在pub / sub中,这对于发布给许多人来说是完美的。 然后我正在考虑使用MongoDB作为一个更永久的数据存储来存储相同的post,这些post将在Redis过期时被访问。

问题:
这个build筑是否有水? 有一个更好的方法吗?
2.关于在Redis和MongoDB中存储post的机制,我正考虑让应用程序做2次写操作:第一次 – 写入Redis,然后立即可用于订阅者。 第二 – 在成功存储到Redis之后,立即写入MongoDB。 这是做这件事的最好方法吗? 我应该让Redis将过期的post推到MongoDB本身吗? 我想到了这一点,但我找不到直接从Redis推送到MongoDB的许多信息。

把Redis和MongoDB联系在一起实际上是明智的:他们是优秀的团队成员。 你会在这里find更多的信息:

MongoDB与Redis

一个关键点就是您需要的弹性级别。 Redis和MongoDB都可以configuration为达到可接受的弹性水平,这些考虑因素应在devise时讨论。 另外,它可能会限制部署选项:如果您希望Redis和MongoDB的主/从复制,至less需要4个checkbox(Redis和MongoDB不应该部署在同一台机器上)。

现在,保持Redis排队,发布/订阅等等可能会更简单一些,并且只将用户数据存储在MongoDB中。 理由是,您不必为两个具有不同范例的商店devise类似的数据访问path(这项工作的困难部分)。 而且,MongoDB具有内置的横向扩展性(副本集,自动分片等),而Redis只有自己动手的可伸缩性。

关于第二个问题,写两个商店将是最简单的方法。 没有内置function将Redis活动复制到MongoDB。 devise一个监听Redis队列的守护进程(活动将被发布)并写入MongoDB并不难。