参考:
http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597071&idx=1&sn=cd8df9f8c52dfbfb54e65adbe19fae27&scene=23&srcid=0509WNSUJdcT5Z2HpGaegBaD#rd
下面是Feed系统的整体架构图:
资源层主要使用Redis、MongoDB、HBase等NoSQL类型数据库。
存储层是内部RPC服务，根据业务场景和存储特性，组合各种数据库资源。
业务层调用存储层读写数据，实现产品逻辑，直接面向用户使用。
陌陌初期采用Mongodb,主要看重无模式的特性,存储JSON方便.
Redis 采用Mod取余Hash的方式.
通过节点数据复制，快速的翻倍扩容，省去了缓存预热的过程。
原文这部分没有细说.
假如原来有三个redis实例,并且各自带了Slave.
通过 id mod 3 取余,判断存放位置.
扩容的时候,仅仅需要把slave Readonly去掉,
前端通过 id mod 6 取余,判断存放位置即可.然后断掉Redis 主从复制.
因为 id mod 6 == 0 的情况 必定 id mod 3 == 0
比如 10 mod 3 = 1 ,现在改为 10 mod 6 = 4 正好 落在原来的备机上.
待完成之后,需要清理每个实例上一半冗余的数据.不过一般设置了过期时间,可以等待他自然过期.
陌陌朋友圈开始用的是推的方式,后来改成拉取.
我倒是觉得推拉结合,似乎更好.
比如
用户9066357的朋友有新消息.
使用时间戳作为Score,内容就是数据库中记录的ID
127.0.0.1:6379> zadd 9066357 20160510112200 101
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112201 102
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112203 103
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112204 104
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112205 105
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112206 106
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112207 107
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112208 108
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112209 109
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112210 110
(integer) 1
用户登录,获取最近的5个消息
127.0.0.1:6379> ZRANGE 9066357 -5 -1
1) "106"
2) "107"
3) "108"
4) "109"
5) "110"
然后除了最近的几个数据,全部删除.
127.0.0.1:6379> ZREMRANGEBYRANK 9066357 0 -8
(integer) 3
127.0.0.1:6379> ZRANGE 9066357 0 -1
1) "104"
2) "105"
3) "106"
4) "107"
5) "108"
6) "109"
7) "110"
保留指定个数的内容.避免内存占用过大.
如果Redis缓存Miss,则查询数据库.
遍历我的好友，找到最近发表过Feed的人
遍历最近发表过Feed的人，得到id和time
合并到我的timeline
http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597071&idx=1&sn=cd8df9f8c52dfbfb54e65adbe19fae27&scene=23&srcid=0509WNSUJdcT5Z2HpGaegBaD#rd
下面是Feed系统的整体架构图:
资源层主要使用Redis、MongoDB、HBase等NoSQL类型数据库。
存储层是内部RPC服务，根据业务场景和存储特性，组合各种数据库资源。
业务层调用存储层读写数据，实现产品逻辑，直接面向用户使用。
陌陌初期采用Mongodb,主要看重无模式的特性,存储JSON方便.
Redis 采用Mod取余Hash的方式.
通过节点数据复制，快速的翻倍扩容，省去了缓存预热的过程。
原文这部分没有细说.
假如原来有三个redis实例,并且各自带了Slave.
通过 id mod 3 取余,判断存放位置.
扩容的时候,仅仅需要把slave Readonly去掉,
前端通过 id mod 6 取余,判断存放位置即可.然后断掉Redis 主从复制.
因为 id mod 6 == 0 的情况 必定 id mod 3 == 0
比如 10 mod 3 = 1 ,现在改为 10 mod 6 = 4 正好 落在原来的备机上.
待完成之后,需要清理每个实例上一半冗余的数据.不过一般设置了过期时间,可以等待他自然过期.
陌陌朋友圈开始用的是推的方式,后来改成拉取.
我倒是觉得推拉结合,似乎更好.
比如
用户9066357的朋友有新消息.
使用时间戳作为Score,内容就是数据库中记录的ID
127.0.0.1:6379> zadd 9066357 20160510112200 101
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112201 102
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112203 103
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112204 104
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112205 105
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112206 106
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112207 107
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112208 108
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112209 109
(integer) 1
127.0.0.1:6379> zadd 9066357 20160510112210 110
(integer) 1
用户登录,获取最近的5个消息
127.0.0.1:6379> ZRANGE 9066357 -5 -1
1) "106"
2) "107"
3) "108"
4) "109"
5) "110"
然后除了最近的几个数据,全部删除.
127.0.0.1:6379> ZREMRANGEBYRANK 9066357 0 -8
(integer) 3
127.0.0.1:6379> ZRANGE 9066357 0 -1
1) "104"
2) "105"
3) "106"
4) "107"
5) "108"
6) "109"
7) "110"
保留指定个数的内容.避免内存占用过大.
如果Redis缓存Miss,则查询数据库.
遍历我的好友，找到最近发表过Feed的人
遍历最近发表过Feed的人，得到id和time
合并到我的timeline
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29254281/viewspace-2096963/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
并发框架Disruptor译文
下一篇：
Hive统计新增,日活和留存率
请登录后发表评论
登录
全部评论
