微信朋友圈技术之道：三个人的后台团队与每日十亿的发布量.pdfVIP

微信朋友圈技术之道 ：三个人的后台团队与每日十亿的发布量 概述 截止到2015 7月 ，微信每月活跃用户约5.4 9亿 ，朋友圈每天的发表量 （包括赞和评论 ）超过10亿 ，浏览量超过100亿。得益于4 G网络的发展 ，以上数据仍有很快的增长 ，而且相对于PC互联网 时代 ，移动互联网时代的峰值要来得更加凶猛。比如 ，2015 元月的流量到了平时的2倍 ，而峰值 则达到了平时峰值的2倍 ，相当于平时正常流量的5倍 ，这对整个系统的考验是很残酷的。本次分享 将简单介绍微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作 ，供各位参考。 团队与技术栈简介 微信后台研发团队由三位工程师组成。开发模式采用了敏捷的方式 ，大概一个月一个小版本 ，一个 季度出一个大版本 ，另外每天都会有不停的后台更新 ，很多是用户看不见的 ，也有一些是A B测试 ， 比如选择一亿的用户 ，或者一定百分比的用户 ，或者一部分男性用户和女性用户来做A B测试。开 发语言主要使用C++ ，正在往C++ 11上迁移 ，编译器在往GCC 4 .8.2迁移。 服务器的配置基本都是普通的服务器 ，最好的服务器也就是64 G内存 ，这部分占比不多 ，大部分 是32G内存 ，也有很少一部分8G内存的。硬盘是SSD和SATA都有。CPU以16核居多 ，有一部分新 机器是32核。至于带宽则是比较多的 ，对外带宽很大。 微信朋友圈的架构概述 整个微信是微服务的架构 ，每一个请求后面可能会涉及到几百个服务 ，每一个服务都有一个Qo S ， 目的是对一些重要的服务进行保证。比如除夕晚上流量达到平时的5倍 ，这时整个系统的性能肯定 不够 ，所以要优先保证什么呢 ？优先保证支付 ，优先保证红包的体验。红包体验保证了 ，再保证 消息 ，比如点对点两人之间的消息。这两个保证的前提下 ，再保证群聊。如果群聊也能保证 ，再保 证朋友圈。性能不够时将优先级低的服务暂时停掉 ，这个过程是不需要人工干预的。 微信的架构跟普通的架构差不多 ，最上面是终端通过接入服务器接进来。接入层主要是长连接 ，长 连接主要是为了安卓系统 ，一个是减少建立新连接的性能消耗 ，另一个是为了推送通知 ，因 为Google服务在国内基本是不可用的 ，安卓系统上的推送通知都是用长连接完成。 然后到逻辑层。逻辑层包括注册、消息、群聊、朋友圈等等 ，还有iO S系统的通知。iO S系统跟安卓 不一样在于 ，一个iO S A pp进入后台之后只有大概15秒的存活期 ，所以iO S上的推送通知要用A PI 的P sh完成 ，不在接入层做。 再往下走就是存储代理层 ，这一层主要负责一些关键数据的维护操作 ，比如用户在账号里面的动作 操作和事故信息。存储代理层下面对接KV存储 ，这个KV存储是不负责业务逻辑的 ，只是单纯 的Key-Val e映射 ，以及负载均衡和容错。 （有关KV存储系统的详细说明 ，可以参考微信架构师许 家滔在Q Co n北京2014上的演讲“微信后台存储架构”。 ） 涉及朋友圈数据的有四个核心的表 ： 一个是发布。发布数据记录了来自所有用户所有的f eed ，比如一个用户发布了几张图片 ，每张图 片的URL是什么 ，在CDN里的URL是什么 ，它有哪些元属性 ，谁可以看 ，谁不可以看等等。 一个是相册。相册是每个用户独立的 ，记录了该用户所发布的所有内容。 一个是评论。评论就是针对某个具体发布的朋友评论和点赞操作。 一个是时间线。所谓“刷朋友圈” ，就是刷时间线 ，就是一个用户所有朋友的发布内容。 上面提到过 ，微信现在每天的发布有10亿多 ，浏览量超过100亿 ，对性能的要求很高 ，所以上面的 存储都是做成可以水平扩展的。对于水平扩展的实现 ，下面举例说明。 微信朋友圈的工作流程概述 比如有两个用户小王和Mary。小王和Mary各自有各自的相册 ，可能在同一台服务器上 ，也可能在不 同的服务器上。现在小王上传了一张图片到自己的朋友圈。上传图片不经过微信后台服务器 ，而是 直接上传到最近的腾讯CDN节点 ，所以非常快。图片上传到该CDN后 ，小王的微信客户端会通知微 信的朋友圈CDN ：这里有一个新的发布 （比如叫K2 ），这个发布的图片URL是什么 ，谁能看到这 些图片 ，等等此类的元数据 ，来把这个发布写到发布的表里。 在发布的表写完之后 ，会把这个K2的发布索引到小王的相册表里。所以相册表其实是很小的 ，里面 只有索引指针。相册表写好了之后 ，会触发一个批处理的动作。这个动作就是去跟小王的每个好 友说 ，小王有一个新的发布 ，请把这个