Redis缓存和架构蒙哥坚持 [英] Architecture for Redis cache & Mongo for persistence
问题描述
设置：
想象一下 twitter like服务，其中用户提交了一个帖子，然后被许多（数百，数千或更多）用户阅读。
我的问题是关于构造缓存的最佳方法&数据库以进行快速访问和优化阅读次数很多，但仍保留历史数据，以便用户（如果需要）可以看到较旧的帖子。这里的假设是90％的用户只会对新内容感兴趣，而旧内容偶尔会被访问。这里的另一个假设是，我们希望针对90％进行优化，如果10％以上的老年人需要更长的时间来检索，这是可以的。
我的研究似乎强烈指出了将缓存用于90％的方向，然后将帖子存储在另一个长期的持久性系统中。因此，到目前为止，我的想法是将Redis用于缓存。它的优点是Redis速度非常快，并且它内置了pub / sub，非常适合将帖子发布给许多人。然后我正在考虑使用MongoDB作为更永久的数据存储来存储相同的帖子，这些帖子在Redis到期后将被访问。
问题：
1.这种建筑是否可以容纳水？有一个更好的方法吗？
2.关于在Redis和Amp中存储帖子的机制。 MongoDB，我当时正在考虑让该应用执行2次写入：1-向Redis写入，然后对订阅者立即可用。第二-成功存储到Redis后，立即写入MongoDB。这是最好的方法吗？我是否应该让Redis将过期的帖子推送到MongoDB本身？我曾考虑过这一点，但找不到直接从Redis推送到MongoDB的信息。
这实际上是明智的与Redis和MongoDB建立联系：他们是优秀的团队合作者。您将在这里找到更多信息：
一个关键点是所需的弹性级别。 Redis和MongoDB都可以配置为达到可接受的弹性水平，并且应在设计时讨论这些注意事项。另外，它可能会限制部署选项：如果您想同时为Redis和MongoDB进行主/从复制，则至少需要4个盒子（Redis和MongoDB不应部署在同一台机器上）。
现在，保留Redis进行排队，发布/订阅等...并仅将用户数据存储在MongoDB中可能会更简单一些。理由是您不必为具有不同范例的两个商店设计类似的数据访问路径（此工作的困难部分）。此外，MongoDB具有内置的水平可伸缩性（副本集，自动分片等），而Redis仅具有自己动手的可伸缩性。
第二个问题，写这两个商店将是最简单的方法。没有内置功能可将Redis活动复制到MongoDB。设计一个监听Redis队列（将发布活动的地方）并写入MongoDB的守护进程并不难。
The Setup:
Imagine a 'twitter like' service where a user submits a post, which is then read by many (hundreds, thousands, or more) users.
My question is regarding the best way to architect the cache & database to optimize for quick access & many reads, but still keep the historical data so that users may (if they want) see older posts. The assumption here is that 90% of users would only be interested in the new stuff, and that the old stuff will get accessed occasionally. The other assumption here is that we want to optimize for the 90%, and its ok if the older 10% take a little longer to retrieve.
With this in mind, my research seems to strongly point in the direction of using a cache for the 90%, and then to also store the posts in another longer-term persistent system. So my idea thus far is to use Redis for the cache. The advantages is that Redis is very fast, and also it has built in pub/sub which would be perfect for publishing posts to many people. And then I was considering using MongoDB as a more permanent data store to store the same posts which will be accessed as they expire off of Redis.
Questions:
1. Does this architecture hold water? Is there a better way to do this?
2. Regarding the mechanism for storing posts in both the Redis & MongoDB, I was thinking about having the app do 2 writes: 1st - write to Redis, it then is immediately available for the subscribers. 2nd - after successfully storing to Redis, write to MongoDB immediately. Is this the best way to do it? Should I instead have Redis push the expired posts to MongoDB itself? I thought about this, but I couldn't find much information on pushing to MongoDB from Redis directly.
It is actually sensible to associate Redis and MongoDB: they are good team players. You will find more information here:
One critical point is the resiliency level you need. Both Redis and MongoDB can be configured to achieve an acceptable level of resiliency, and these considerations should be discussed at design time. Also, it may put constraint on the deployment options: if you want master/slave replication for both Redis and MongoDB you need at least 4 boxes (Redis and MongoDB should not be deployed on the same machine).
Now, it may be a bit simpler to keep Redis for queuing, pub/sub, etc ... and store the user data in MongoDB only. Rationale is you do not have to design similar data access paths (the difficult part of this job) for two stores featuring different paradigms. Also, MongoDB has built-in horizontal scalability (replica sets, auto-sharding, etc ...) while Redis has only do-it-yourself scalability.
Regarding the second question, writing to both stores would be the easiest way to do it. There is no built-in feature to replicate Redis activity to MongoDB. Designing a daemon listening to a Redis queue (where activity would be posted) and writing to MongoDB is not that hard though.
这篇关于Redis缓存和架构蒙哥坚持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
