如何扛住100亿次请求？后端架构应该这样设计！

1. 前言

前几天，偶然看到了 《扛住100亿次请求——如何作一个“有把握”的春晚红包系统”》一文，看完之后，感慨良多，收益不少。正所谓他山之石，能够攻玉，虽然此文发表于2015年，我看到时已通过去良久，可是其中的思想仍然是能够为不少后端设计借鉴。

同时做为一微信后端工程师，看完之后又会思考，学习了这样的文章之后，是否能给本身的工做带来一些实际的经验呢？所谓纸上得来终觉浅，绝知此事要躬行，可否本身实践一下100亿次红包请求呢？不然读完之后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼，剩下的文章将展现做者是如何以此过程为目标，在本地环境的模拟了此过程。

实现的目标：单机支持100万链接，模拟了摇红包和发红包过程，单机峰值QPS 6万，平稳支持了业务。

注：本文以及做者全部内容，仅表明我的理解和实践，过程和微信团队没有任何关系，真正的线上系统也不一样，只是从一些技术点进行了实践，请读者进行区分。

2. 背景知识

QPS：Queries per second 每秒的请求数目

PPS：Packets per second 每秒数据包数目

摇红包：客户端发出一个摇红包的请求，若是系统有红包就会返回，用户得到红包

发红包：产生一个红包里面含有必定金额，红包指定数个用户，每一个用户会收到红包信息，用户能够发送拆红包的请求，获取其中的部分金额。

3. 肯定目标

在一切系统开始之前，咱们应该搞清楚咱们的系统在完成之后，应该有一个什么样的负载能力。

3.1 用户总数

经过文章咱们能够了解到接入服务器638台，服务上限大概是14.3亿用户， 因此单机负载的用户上限大概是14.3亿/638台=228万用户/台。可是目前中国确定不会有14亿用户同时在线，参考 http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html的说法，2016年Q2 微信用户大概是8亿，月活在5.4 亿左右。因此在2015年春节期间，虽然使用的用户会不少，可是同时在线确定不到5.4亿。

3.2. 服务器数量

一共有638台服务器，按照正常运维设计，我相信全部服务器不会彻底上线，会有必定的硬件冗余，来防止突发硬件故障。假设一共有600台接入服务器。

3.3 单机须要支持的负载数

每台服务器支持的用户数：5.4亿/600 = 90万。也就是平均单机支持90万用户。若是真实状况比90万更多，则模拟的状况可能会有误差，可是我认为QPS在这个实验中更重要。

3.4. 单机峰值QPS

文章中明确表示为1400万QPS.这个数值是很是高的，可是由于有600台服务器存在，因此单机的QPS为 1400万/600= 约为2.3万QPS, 文章曾经说起系统能够支持4000万QPS，那么系统的QPS 至少要到4000万/600 = 约为 6.6万, 这个数值大约是目前的3倍，短时间来看并不会被触及。可是我相信应该作过相应的压力测试。

3.5. 发放红包

文中提到系统以5万个每秒的下发速度，那么单机每秒下发速度50000/600 ＝83个/秒，也就是单机系统应该保证每秒以83个的速度下发便可。

最后考虑到系统的真实性，还至少有用户登陆的动做，拿红包这样的业务。真实的系统还会包括聊天这样的服务业务。

最后总体的看一下 100亿次摇红包这个需求，假设它是均匀地发生在春节联欢晚会的4个小时里，那么服务器的QPS 应该是10000000000/600/3600/4.0=1157. 也就是单机每秒1000屡次，这个数值其实并不高。若是彻底由峰值速度1400万消化 10000000000/(1400*10000) = 714秒，也就是说只须要峰值坚持11分钟，就能够完成全部的请求。可见互联网产品的一个特色就是峰值很是高，持续时间并不会很长。

总结

从单台服务器看，它须要知足下面一些条件：

支持至少100万链接用户

每秒至少能处理2.3万的QPS，这里咱们把目标定得更高一些 分别设定到了3万和6万。

摇红包：支持每秒83个的速度下发放红包，也就是说每秒有2.3万次摇红包的请求，其中83个请求能摇到红包，其他的2.29万次请求会知道本身没摇到。固然客户端在收到红包之后，也须要确保客户端和服务器两边的红包数目和红包内的金额要一致。由于没有支付模块，因此咱们也把要求提升一倍，达到200个红包每秒的分发速度

支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。一样也设定200个红包每秒的分发速度为咱们的目标。

想完整模拟整个系统实在太难了，首先须要海量的服务器，其次须要上亿的模拟客户端。这对我来讲是办不到，可是有一点能够肯定，整个系统是能够水平扩展的，因此咱们能够模拟100万客户端，在模拟一台服务器 那么就完成了1/600的模拟。

和现有系统区别：和大部分高QPS测试的不一样，本系统的侧重点有所不一样。我对2者作了一些对比。

4. 基础软件和硬件

4.1软件

Golang 1.8r3 , shell, python (开发没有使用c++ 而是使用了golang, 是由于使用golang 的最初原型达到了系统要求。虽然golang 还存在必定的问题，可是和开发效率比，这点损失能够接受)

服务器操做系统：Ubuntu 12.04

客户端操做系统：debian 5.0

4.2硬件环境

服务端：dell R2950。8核物理机，非独占有其余业务在工做，16G内存。这台硬件大概是7年前的产品，性能应该不是很高要求。

服务器硬件版本：

服务器CPU信息：

客户端：esxi 5.0 虚拟机，配置为4核 5G内存。一共17台，每台和服务器创建6万个链接。完成100万客户端模拟

5. 技术分析和实现

5.1) 单机实现100万用户链接

这一点来讲相对简单，笔者在几年前就早完成了单机百万用户的开发以及操做。现代的服务器均可以支持百万用户。相关内容能够查看：

github代码以及相关文档：

https://github.com/xiaojiaqi/C1000kPracticeGuide 

架构学习方法：

《2019年架构师系统进阶资料免费领取https://shimo.im/docs/8twXWVtKRHwrHrpT/》

系统配置以及优化文档： 

https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn 

5.2) 3万QPS

这个问题须要分2个部分来看客户端方面和服务器方面。

客户端QPS

由于有100万链接连在服务器上，QPS为3万。这就意味着每一个链接每33秒，就须要向服务器发一个摇红包的请求。由于单IP能够创建的链接数为6万左右， 有17台服务器同时模拟客户端行为。咱们要作的就保证在每一秒都有这么多的请求发往服务器便可。

其中技术要点就是客户端协同。可是各个客户端的启动时间，创建链接的时间都不一致，还存在网络断开重连这样的状况，各个客户端如何判断什么时候本身须要发送请求，各自该发送多少请求呢？

我是这样解决的：利用NTP服务，同步全部的服务器时间，客户端利用时间戳来判断本身的此时须要发送多少请求。

算法很容易实现：假设有100万用户，则用户id 为0-999999.要求的QPS为5万， 客户端得知QPS为5万，总用户数为100万，它计算 100万/5万=20，全部的用户应该分为20组，若是 time() % 20 == 用户id % 20，那么这个id的用户就该在这一秒发出请求，如此实现了多客户端协同工做。每一个客户端只须要知道 总用户数和QPS 就能自行准确发出请求了。

（扩展思考：若是QPS是3万 这样不能被整除的数目，该如何办？如何保证每台客户端发出的请求数目尽可能的均衡呢？）

服务器QPS

服务器端的QPS相对简单，它只须要处理客户端的请求便可。可是为了客观了解处理状况，咱们还须要作2件事情。

第一：须要记录每秒处理的请求数目，这须要在代码里埋入计数器。

第二：咱们须要监控网络，由于网络的吞吐状况，能够客观的反映出QPS的真实数据。为此，我利用python脚本 结合ethtool 工具编写了一个简单的工具，经过它咱们能够直观的监视到网络的数据包经过状况如何。它能够客观的显示出咱们的网络有如此多的数据传输在发生。

工具截图： 

5.3) 摇红包业务

摇红包的业务很是简单，首先服务器按照必定的速度生产红包。红包没有被取走的话，就堆积在里面。服务器接收一个客户端的请求，若是服务器里如今有红包就会告诉客户端有，不然就提示没有红包。

由于单机每秒有3万的请求，因此大部分的请求会失败。只须要处理好锁的问题便可。

我为了减小竞争，将全部的用户分在了不一样的桶里。这样能够减小对锁的竞争。若是之后还有更高的性能要求，还可使用 高性能队列——Disruptor来进一步提升性能。

注意，在个人测试环境里是缺乏支付这个核心服务的，因此实现的难度是大大的减轻了。另外提供一组数字：2016年淘宝的双11的交易峰值仅仅为12万/秒，微信红包分发速度是5万/秒，要作到这点是很是困难的。（http://mt.sohu.com/20161111/n472951708.shtml）

5.4) 发红包业务

发红包的业务很简单，系统随机产生一些红包，而且随机选择一些用户，系统向这些用户提示有红包。这些用户只须要发出拆红包的请求，系统就能够随机从红包中拆分出部分金额，分给用户，完成这个业务。一样这里也没有支付这个核心服务。

5.5）监控

最后 咱们须要一套监控系统来了解系统的情况，我借用了我另外一个项目(https://github.com/xiaojiaqi/fakewechat) 里的部分代码完成了这个监控模块，利用这个监控，服务器和客户端会把当前的计数器内容发往监控，监控须要把各个客户端的数据作一个整合和展现。同时还会把日志记录下来，给之后的分析提供原始数据。线上系统更多使用opentsdb这样的时序数据库，这里资源有限，因此用了一个原始的方案。

监控显示日志大概这样：

6. 代码实现及分析

在代码方面，使用到的技巧实在很少，主要是设计思想和golang自己的一些问题须要考虑。

首先golang的goroutine 的数目控制，由于至少有100万以上的链接，因此按照普通的设计方案，至少须要200万或者300万的goroutine在工做。这会形成系统自己的负担很重。

其次就是100万个链接的管理，不管是链接仍是业务都会形成一些心智的负担。

个人设计是这样的：

首先将100万链接分红多个不一样的SET，每一个SET是一个独立，平行的对象。每一个SET 只管理几千个链接，若是单个SET 工做正常，我只须要添加SET就能提升系统处理能力。

其次谨慎的设计了每一个SET里数据结构的大小，保证每一个SET的压力不会太大，不会出现消息的堆积。

再次减小了gcroutine的数目，每一个链接只使用一个goroutine,发送消息在一个SET里只有一个gcroutine负责，这样节省了100万个goroutine。这样整个系统只须要保留 100万零几百个gcroutine就能完成业务。大量的节省了cpu 和内存

系统的工做流程大概是：每一个客户端链接成功后，系统会分配一个goroutine读取客户端的消息，当消息读取完成，将它转化为消息对象放至在SET的接收消息队列，而后返回获取下一个消息。

在SET内部，有一个工做goroutine，它只作很是简单而高效的事情，它作的事情以下，检查SET的接受消息，它会收到3类消息

客户端的摇红包请求消息

客户端的其余消息 好比聊天 好友这一类

服务器端对客户端消息的回应

对于第1种消息客户端的摇红包请求消息 是这样处理的，从客户端拿到摇红包请求消息，试图从SET的红包队列里 获取一个红包，若是拿到了就把红包信息 返回给客户端，不然构造一个没有摇到的消息，返回给对应的客户端。

对于第2种消息客户端的其余消息 好比聊天 好友这一类，只需简单地从队列里拿走消息，转发给后端的聊天服务队列便可，其余服务会把消息转发出去。

对于第3种消息服务器端对客户端消息的回应。SET 只须要根据消息里的用户id，找到SET里保留的用户链接对象，发回去就能够了。

对于红包产生服务，它的工做很简单，只须要按照顺序在轮流在每一个SET的红包产生对列里放至红包对象就能够了。这样能够保证每一个SET里都是公平的，其次它的工做强度很低，能够保证业务稳定。

见代码：

https://github.com/xiaojiaqi/10billionhongbaos

7. 实践

实践的过程分为3个阶段

阶段1

分别启动服务器端和监控端，而后逐一启动17台客户端，让它们创建起100万的连接。在服务器端，利用ss 命令 统计出每一个客户端和服务器创建了多少链接。

命令以下：

Alias ss2=Ss –ant |grep1025|grepEST | awk –F: “{print\$8}” |sort| uniq –c’

结果以下： 

阶段2

利用客户端的http接口，将全部的客户端QPS 调整到3万，让客户端发出3W QPS强度的请求。

运行以下命令：

观察网络监控和监控端反馈，发现QPS 达到预期数据，网络监控截图：

在服务器端启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包，总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。

等到全部红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每一个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后全部的红包都被拿走。

阶段3

利用客户端的http接口，将全部的客户端QPS 调整到6万，让客户端发出6W QPS强度的请求。

如法炮制，在服务器端，启动一个产生红包的服务，这个服务会以200个每秒的速度下发红包。总共4万个。此时观察客户端在监控上的日志，会发现基本上以200个每秒的速度获取到红包。

等到全部红包下发完成后，再启动一个发红包的服务，这个服务系统会生成2万个红包，每秒也是200个，每一个红包随机指定3位用户，并向这3个用户发出消息，客户端会自动来拿红包，最后全部的红包都被拿走。

最后，实践完成。

8. 分析数据

在实践过程当中，服务器和客户端都将本身内部的计数器记录发往监控端，成为了日志。咱们利用简单python 脚本和gnuplt 绘图工具，将实践的过程可视化，由此来验证运行过程。

第一张是客户端的QPS发送数据：

这张图的横坐标是时间，单位是秒，纵坐标是QPS，表示这时刻全部客户端发送的请求的QPS。

图的第一区间，几个小的峰值，是100万客户端创建链接的， 图的第二区间是3万QPS 区间，咱们能够看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。可是从整张图能够看到QPS不是完美地保持在咱们但愿的直线上。这主要是如下几个缘由形成的

 

1. 当很是多goroutine 同时运行的时候，依靠sleep 定时并不许确，发生了偏移。我以为这是golang自己调度致使的。固然若是cpu比较强劲，这个现象会消失。

2. 由于网络的影响，客户端在发起链接时，可能发生延迟，致使在前1秒没有完成链接。

3. 服务器负载较大时，1000M网络已经出现了丢包现象，能够经过ifconfig 命令观察到这个现象，因此会有QPS的波动。

第二张是 服务器处理的QPS图：

和客户端的向对应的，服务器也存在3个区间，和客户端的状况很接近。可是咱们看到了在大概22：57分，系统的处理能力就有一个明显的降低，随后又提升的尖状。这说明代码还须要优化。

总体观察在3万QPS区间，服务器的QPS比较稳定，在6万QSP时候，服务器的处理就不稳定了。我相信这和个人代码有关，若是继续优化的话，还应该能有更好的效果。

将2张图合并起来 ：

基本是吻合的，这也证实系统是符合预期设计的。

这是红包生成数量的状态变化图：

很是的稳定。

这是客户端每秒获取的摇红包状态：

能够发现3万QPS区间，客户端每秒获取的红包数基本在200左右，在6万QPS的时候，以及出现剧烈的抖动，不能保证在200这个数值了。我以为主要是6万QPS时候，网络的抖动加重了，形成了红包数目也在抖动。

最后是golang 自带的pprof 信息，其中有gc 时间超过了10ms, 考虑到这是一个7年前的硬件，并且非独占模式，因此仍是能够接受。

总结

按照设计目标，咱们模拟和设计了一个支持100万用户，而且每秒至少能够支持3万QPS，最多6万QPS的系统，简单模拟了微信的摇红包和发红包的过程。能够说达到了预期的目的。

若是600台主机每台主机能够支持6万QPS，只须要7分钟就能够完成 100亿次摇红包请求。

虽然这个原型简单地完成了预设的业务，可是它和真正的服务会有哪些差异呢？我罗列了一下

 

Refers： 

• 单机百万的实践

• https://github.com/xiaojiaqi/C1000kPracticeGuide

• 如何在AWS上进行100万用户压力测试

• https://github.com/xiaojiaqi/fakewechat/wiki/Stress-Testing-in-the-Cloud

• 构建一个你本身的类微信系统

• https://github.com/xiaojiaqi/fakewechat/wiki/Design

• http://djt.qq.com/article/view/1356

• http://techblog.cloudperf.net/2016/05/2-million-packets-per-second-on-public.html

• http://datacratic.com/site/blog/1m-qps-nginx-and-ubuntu-1204-ec2

• @火丁笔记

• http://huoding.com/2013/10/30/296

• https://gobyexample.com/non-blocking-channel-operations