微信朋友圈高性能复杂度
微信朋友圈总体复杂度属于质量复杂度高,业务复杂度低的区间,原因如下:
微信朋友圈业务逻辑比较简单:发动态、评论、点赞
除了热点新闻事件或者节假日情况下,其他时间段不会发生高并发事件,有点类似红包这样的功能
综上所述:朋友圈属于质量复杂度高,业务复杂度低的区间
朋友圈的复杂度分析

朋友圈高性能方案--发动态

发动态架构图

采用 Hash 算法是为了根据每一个朋友圈动态的 ID 分配到一个服务器上去进行处理,这样处理性能是最高的,方便后续的点赞、评论都在该机器上去处理。
另外考虑到有一些动态是图片之类的,该类数据可以存放到 fastDFS 上,mysql 中存储对应的路径 ID 即可。
朋友圈高性能方案--点赞

点赞架构图

这里考虑到点赞并发度高,而且后续要永久存储用于历史翻阅,所以首先使用 redis 存储点赞信息,后续采用异步的方式存储到关系型数据库中
朋友圈高性能方案--评论

评论架构图

评论