微信朋友圈技术实现探讨

sosojustdo 15-10-21
         

请教大家一个问题,微博关注好友动态主页,和微信朋友圈动态列表,后端架构设计都是如何实现的?
自己想到的是:
方案一:
1:首选是取我的好友列表,这个有自己的好友列表cache维护,不能直接查询db,考虑到数据量很大情况下的伸缩性必须满足。
2:再根据我的好友ids再去取他们发表的微博或者动态,按照时间排序,这个无疑是拿着user_ids in 动态数据表,这点感觉性能很致命。

方案二:
对比方案一,关系性数据库在面临大数据的时候系能会显得比较疲惫,考虑采用NOSQL,如:Mongodb,HBase ,Redis等产品。
综合对比,倾向选用HBase。Mongodb莫名丢数据时而常有的事情;Redis Master-Slave结构面临单机内存垂直增长受限,Redis 3.0目前支持Cluster,配合Sentinel,貌似能保证sharding nothing又能保证高可用,但是Redis Cluster生产环境没有实用经验。

大家有什么好的建议呢?

         

2
sosojustdo
2015-10-21 18:33

方案二还得补充一点就是代码上线前,需要处理已有好友关系的动态数据存储,从mysql考虑用job一次性跑到nosql中,这样保证我关注的人,先前发的动态我也能看到。

banq
2015-10-22 06:43

可以考虑Cassandra和Neo4j

sosojustdo
2015-10-22 10:02

Neo4j属于图数据库,的确是适合存储好友关系这种关系节点的类型数据,无论是查看我关注的和相互关注的好友,根据relatioship能很快查询出来,不过Neo4j有收费企业版和免费版,@banq选择免费版的就可以吗?

Cassandra和HBase对比,@banq为啥推荐使用Cassandra?

sosojustdo
2015-10-22 10:35

逛了一圈知乎,貌似大家在HBase和Cassandra的选择上,更加倾向于前者,原因有如下几点:
1:遭受很多国外大型互联网公司的弃用,而且文档和社区落伍不太活跃,同时运维成本也比HBase高出一筹。
2:在CAP特性上,HBase选择了CP,Cassandra更倾向于AP,而在一致性上有所减弱。
3:Cassandra数据压缩时,读写性能急剧低下。
4:不支持直接接入hadoop,不能实现MapReduce。
5:也有说频繁GC,导致读写性能低下的情况(这种情况,我多半怀疑是配置或者jvm调优没有做好)

2Go 1 2 下一页