架构之道:3个程序员成就微信朋友圈日均10亿发布量

前言

截止到2015年7月,微信每月活跃用户约5.49亿,朋友圈每天的发表量(包括赞和评论)超过10亿,浏览量超过100亿。得益于4G网络的发展,以上数据仍有很快的增长,而且相对于PC互联网时代,移动互联网时代的峰值要来得更加凶猛。比如,2015年元月的流量到了平时的2倍,而峰值则达到了平时峰值的2倍,相当于平时正常流量的5倍,这对整个系统的考验是很残酷的。本次分享将简单介绍微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作,供各位参考。

基本介绍

服务器的配置基本都是普通的服务器,最好的服务器也就是64G内存,这部分占比不多,大部分是32G内存,也有很少一部分8G内存的。硬盘是SSD和SATA都有。CPU以16核居多,有一部分新机器是32核。至于带宽则是比较多的,对外带宽很大。

架构概述

整个微信是微服务的架构,每一个请求后面可能会涉及到几百个服务,每一个服务都有一个QoS,目的是对一些重要的服务进行保证。比如除夕晚上流量达到平时的5倍,这时整个系统的性能肯定不够,所以要优先保证什么呢?优先保证支付,优先保证红包的体验。红包体验保证了,再保证消息,比如点对点两人之间的消息。这两个保证的前提下,再保证群聊。如果群聊也能保证,再保证朋友圈。性能不够时将优先级低的服务暂时停掉,这个过程是不需要人工干预的。

然后到逻辑层。逻辑层包括注册、消息、群聊、朋友圈等等,还有iOS系统的通知。iOS系统跟安卓不一样在于,一个iOS App进入后台之后只有大概15秒的存活期,所以iOS上的推送通知要用API的Push完成,不在接入层做。 再往下走就是存储代理层,这一层主要负责一些关键数据的维护操作,比如用户在账号里面的动作操作和事故信息。存储代理层下面对接KV存储,这个KV存储是不负责业务逻辑的,只是单纯的Key-Value映射,以及负载均衡和容错。(有关KV存储系统的详细说明,可以参考微信架构师许家滔在QCon北京2014上的演讲“微信后台存储架构”。) 涉及朋友圈数据的有四个核心的表:

上面提到过,微信现在每天的发布有10亿多,浏览量超过100亿,对性能的要求很高,所以上面的存储都是做成可以水平扩展的。对于水平扩展的实现,下面举例说明。

应用原理

在发布的表写完之后,会把这个K2的发布索引到小王的相册表里。所以相册表其实是很小的,里面只有索引指针。相册表写好了之后,会触发一个批处理的动作。这个动作就是去跟小王的每个好友说,小王有一个新的发布,请把这个发布插入到每个好友的时间线里面去。 然后比如说现在Mary上朋友圈了,而Mary是小王的一个好友。Mary拉自己的时间线的时候,时间线会告诉到有一个新的发布K2,然后Mary的微信客户端就会去根据K2的元数据去获取图片在CDN上的URL,把图片拉到本地。 在这个过程中,发布是很重的,因为一方面要写一个自己的数据副本,然后还要把这个副本的指针插到所有好友的时间线里面去。如果一个用户有几百个好友的话,这个过程会比较慢一些。这是一个单数据副本写扩散的过程。但是相对应的,读取就很简单了,每一个用户只需要读取自己的时间线表,就这一个动作就行,而不需要去遍历所有好友的相册表。 为什么选择这样一个写扩散的模型?因为读是有很多失败的。一个用户如果要去读两百个好友的相册表,极端情况下可能要去两百个服务器上去问,这个失败的可能性是很大的。但是写失败了就没关系,因为写是可以等待的,写失败了就重新去拷贝,直到插入成功为止。所以这样一个模型可以很大的减少服务的开销。 至于赞和评论的实现,是相对简单的。上面说了微信后台有一个专门的表存储评论和赞的数据,比如Kate是Mary和小王的朋友的话,刷到了K2这一条发布,就会同时从评论表里面拉取对应K2的、Mary留下的评论内容,插入到K2内容的下方。而如果另一个人不是Mary和小王的共同朋友,则不会看到这条评论。

容灾方案

第二个层次的容灾是跨地域的。微信最早在国内有一个上海的数据中心,这个数据中心承载了全国所有的用户。后来有一天上海来了个海啸还是什么的,所有数据都没了,于是后来在深圳又建立一个数据中心,上海服务北方用户,深圳服务南方。后来因为微信发展海外用户,于是在香港建立了第三个数据中心,主要服务东南亚、南亚、中东和非洲。后来在加拿大又建立了第四个数据中心,主要服务美洲和欧洲。 这第二个层次的数据中心跟上面说的园区不太一样。每一个微信用户事实上都属于一个特定的数据中心,比如两个北方的用户,他们的数据都在上海的数据中心,如果说上海数据中心跟其他数据中心的连接断了,这两个用户之间的通信是不会受到影响的。但如果有一个外国朋友在加拿大的数据中心,那么他跟国内用户的通信就可能受到影响。数据中心之间是有专线连接的,但实际上国内到国外的专线渠道并不太有保障,所以专线出问题的时候,两个数据中心之间的数据交换会切换到公网上,走普通的互联网。 新建一个数据中心涉及到很多同步,微信消息的数据同步是通过一个idcqueue组件实现的,是一个异步的数据同步方式。这个异步的写操作可能会由于网络阻塞或者其他原因,慢个一两秒种、几分钟甚至半天,但它会一直重试,能够保持正确性。而对于朋友圈来说,朋友圈是多数据副本的模型,那么多数据副本在跨数据中心同步的时候如何保证正确性,如何保证没有冲突?

当然有关这一块还有很多细节的问题,尤其是因为国内到国外的网络延迟很大,从大陆ping美国可能两百个毫秒,ping阿根廷或者南非可能有四百个毫秒,另外公网的丢包也比较严重,这对于数据同步的实现是很有影响的。这种情况就不适合用TCP了,TCP是针对大带宽、小延迟、有序的环境设计的,所以微信在跨数据中心做数据同步这一块就自己研发了一套类TCP的协议,这种协议对高延迟、高丢包有很高的容忍度,能够做到每秒同步几百兆到上G的数据。另一方面,由于从专线切换到公网存在信息安全隐患,这其中的数据加密也是很重要的一个工作。

原文发布于微信公众号 - IT技术精选文摘(ITHK01)

原文发表时间:2018-05-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏互扯程序

千万级规模高性能、高并发的网络架构经验分享

现在是资源共享的时代,同样也是知识分享的时代,如果你觉得本文能学到知识,请把知识与别人分享。

1106
来自专栏架构之美

微服务架构在二手交易平台(转转)中的实践

1041
来自专栏Java后端技术

分布式架构的前世今生...

​  随着社会的发展,技术的进步,以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的分布式架构,从大型机到分布式,经...

792
来自专栏即时通讯技术

【原创】新手入门一篇就够:从零开发移动端IM一、前言 二、读完本文的收获三、题外话四、网络编程理论准备五、网络编程基础实践六、IM到底该用UDP还是TCP协议?七、IM的数据通信格式选型八、移动端IM

IM发展至今,已是非常重要的互联网应用形态之一,尤其移动互联网时代,它正以无与论比的优势降低了沟通成本和沟通代价,对各种应用形态产生了深远影响。

652
来自专栏SDNLAB

SDN技术分享(十):GoogleFiber的宽带接入速率控制解决方案

本次分(zhuang)享(bi)呢,主要探讨一个新兴SP客户的案例。 G家,这是非传统的SP。我们一起来看一下G家的市场策略以及使用的关键技术. 内容比较多,我...

37513
来自专栏沈钦华的专栏

腾讯海量数据仓库运维系统 : 鹦鹉螺

面对腾讯 SNG 海量的数据服务,数十亿 qps、上万台机器设备、繁多的数据库组件和多种网络环境,数据运维组如何应对这些挑战、怎样将人力从繁复的运维中释放出来?

3780
来自专栏IT技术精选文摘

解密腾讯海量服务之道

一直对腾讯做产品的能力比较敬佩的,我们组做消息推送系统,而腾讯的信鸽就是我们学习的榜样。京东很多做产品的思想是跟腾讯学的,而京东很多同事也从腾讯过来的(京东合并...

3605
来自专栏张善友的专栏

千万级规模高性能、高并发的网络架构经验分享

主 题 :INTO100沙龙 时间 :2015年11月21日下午 地点 :梦想加联合办公空间 分享人:卫向军(毕业于北京邮电大学,现任微博平台架构师,先后在微软...

3736
来自专栏JAVA高级架构

饿了么:日订单量超900万的架构设计及演进之路

网站在刚开始的时候大概只是一个想法:一个产业的模型,快速地将它产生出来。“快”是第一位的,不需要花太多精力在架构设计上。在网站进入扩张期才需要对架构投入更多的精...

592
来自专栏阿杜的世界

【转】交易系统在分布式环境下的问题探讨

众所周知在互联网公司,如果你没有对你的系统进行分库分表,那你怎么好意思跟人打招呼?但是分库分表带来的难题也是众所周知的,除了多机查询(分批查询、合并结果等等)等...

483

扫码关注云+社区