微信朋友圈的高性能复杂度

一、业务复杂度分析

业务场景评估

预估使用朋友圈人数为 1 亿人，每天朋友圈消息 20 条，朋友圈评论 20 条，点赞 20 次；每天用户刷新朋友圈及客户端拉取（或推送）100 次。

以发消息及消息评论该场景进行评估，每天有 20 亿的消息会被发送，每秒平均约 50 万条消息，按忙时为白天 12 小时，则峰值估计 100 万条消息。而点赞及评论小时则为 40 亿条，峰值估计 100 万条记录。

按刷新朋友圈场景来看，每天请求次数为 100 亿次，峰值请求约为 1000 万次。

复杂度：

业务复杂度：中，整个业务场景主要围绕消息的发布及对消息的操作评论、通知方式，客户端的读取通知及刷新查看消息。但整体量级非常大。

质量复杂度：中，发送消息需要保障成功率，但消息通知不需要立即被响应。用户侧的数据刷新允许有分钟级的时延。

二、按厂家评估架构

发朋友圈场景

因为是微信朋友圈，用户关系设定为直接应用微信已有用户信息，不考虑该方面的设计。

场景：包含发消息、点赞、评论等都伟发消息。消息的每秒发送量及相应的存储量都是非常大。且消息需要对客户端能有通知要求。

存储方面：海量数据需要存储到分布式存储中，海量数据写入使用队列方式作为写缓存。消息发送完需要有通知也写入缓存。数据持久化后保存到分布式存储里。另外实时数据如当天的消息，也按热数据保存写到缓存中一份。历史数据如果要查询，可以从分布式存储写入到 hbase 中。

计算方面：写操作都作为同一服务节点中能力。

刷朋友圈场景

场景：包含阅读通知、刷新查看消息，查看历史消息。

计算方面：通知、当天消息等大量的读操作，直接读取缓存。历史数据可以从 hbase 中读取。

存储方面：不涉及。

三、整体架构