|
|
51CTO旗下网站
|
|
移动端

扛住100亿次红包请求的架构是这样设计的!

偶然看到了《扛住 100 亿次请求——如何做一个“有把握”的春晚红包系统》一文,看完以后,感慨良多,收益很多。

作者:xiaojiaqi来源:Github|2020-03-26 08:07

偶然看到了《扛住 100 亿次请求——如何做一个“有把握”的春晚红包系统》一文,看完以后,感慨良多,收益很多。

图片来自 Pexels

正所谓他山之石,可以攻玉,虽然此文发表于 2015 年,我看到时已经过去良久,但是其中的思想仍然可以为很多后端设计借鉴。

同时作为一名微信后端工程师,看完以后又会思考,学习了这样的文章以后,是否能给自己的工作带来一些实际的经验呢?所谓纸上得来终觉浅,绝知此事要躬行,能否自己实践一下 100 亿次红包请求呢?

否则读完以后脑子里能剩下的东西不过就是 100 亿,1400 万 QPS 整流这样的字眼,剩下的文章将展示作者是如何以此过程为目标,在本地环境的模拟了此过程。

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

注:本文以及作者所有内容,仅代表个人理解和实践,过程和微信团队没有任何关系,真正的线上系统也不同,只是从一些技术点进行了实践,请读者进行区分。

背景知识

QPS:Queries per second(每秒的请求数目)。

PPS:Packets per second(每秒数据包数目)。

摇红包:客户端发出一个摇红包的请求,如果系统有红包就会返回,用户获得红包。

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

确定目标

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

用户总数

通过文章我们可以了解到接入服务器 638 台,服务上限大概是 14.3 亿用户, 所以单机负载的用户上限大概是 14.3 亿/638 台=228 万用户/台。

但是目前中国肯定不会有 14 亿用户同时在线,参考的说法:

  1. http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html 

2016 年 Q2 微信用户大概是 8 亿,月活在 5.4 亿左右。所以在 2015 年春节期间,虽然使用的用户会很多,但是同时在线肯定不到 5.4 亿。

服务器数量

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

单机需要支持的负载数

每台服务器支持的用户数:5.4 亿/ 600=90 万。也就是平均单机支持 90 万用户。

如果真实情况比 90 万更多,则模拟的情况可能会有偏差,但是我认为 QPS 在这个实验中更重要。

单机峰值 QPS

文章中明确表示为 1400 万 QPS。这个数值是非常高的,但是因为有 600 台服务器存在,所以单机的 QPS 为 1400 万/600=约为 2.3 万 QPS。

文章曾经提及系统可以支持 4000 万 QPS,那么系统的 QPS 至少要到 4000 万/ 600=约为 6.6 万,这个数值大约是目前的 3 倍,短期来看并不会被触及。但是我相信应该做过相应的压力测试。

发放红包

文中提到系统以 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 测试的不同,本系统的侧重点有所不同。

我对两者做了一些对比:

基础软件和硬件

软件

Golang 1.8r3,Shell,Python(开发没有使用 C++ 而是使用了 Golang,是因为使用 Golang 的最初原型达到了系统要求。虽然 Golang 还存在一定的问题,但是和开发效率比,这点损失可以接受)。

服务器操作系统:Ubuntu 12.04。

客户端操作系统:debian 5.0。

硬件环境

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

服务器硬件版本:

服务器 CPU 信息:

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

技术分析和实现

单机实现 100 万用户连接

这一点来说相对简单,笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看 Github 代码以及相关文档、系统配置以及优化文档。

参考链接:

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

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 工具编写了一个简单的工具,通过它我们可以直观地监视到网络的数据包通过情况如何。它可以客观地显示出我们的网络有如此多的数据传输在发生。

工具截图:

摇红包业务

摇红包的业务非常简单,首先服务器按照一定的速度生产红包。红包没有被取走的话,就堆积在里面。

服务器接收一个客户端的请求,如果服务器里现在有红包就会告诉客户端有,否则就提示没有红包。

因为单机每秒有 3 万的请求,所以大部分的请求会失败。只需要处理好锁的问题即可。

我为了减少竞争,将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。

如果以后还有更高的性能要求,还可以使用高性能队列——Disruptor 来进一步提高性能。

注意,在我的测试环境里是缺少支付这个核心服务的,所以实现的难度是大大地减轻了。

另外提供一组数字:2016 年淘宝的双 11 的交易峰值仅仅为 12 万/秒,微信红包分发速度是 5 万/秒,要做到这点是非常困难的。

参考链接:

  1. http://mt.sohu.com/20161111/n472951708.shtml 

发红包业务

发红包的业务很简单,系统随机产生一些红包,并且随机选择一些用户,系统向这些用户提示有红包。

这些用户只需要发出拆红包的请求,系统就可以随机从红包中拆分出部分金额,分给用户,完成这个业务。同样这里也没有支付这个核心服务。

监控

最后,我们需要一套监控系统来了解系统的状况,我借用了我另一个项目里的部分代码完成了这个监控模块,利用这个监控,服务器和客户端会把当前的计数器内容发往监控,监控需要把各个客户端的数据做一个整合和展示。

同时还会把日志记录下来,给以后的分析提供原始数据。线上系统更多使用 opentsdb 这样的时序数据库,这里资源有限,所以用了一个原始的方案。

参考链接:

  1. https://github.com/xiaojiaqi/fakewechat 

监控显示日志大概这样:

代码实现及分析

在代码方面,使用到的技巧实在不多,主要是设计思想和 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 里都是公平的,其次它的工作强度很低,可以保证业务稳定。

参考链接:

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

实践

实践的过程分为三个阶段:

阶段 1

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

命令如下:

  1. Alias ss2=Ss –ant | grep 1025 | grep EST | 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 个用户发出消息,客户端会自动来拿红包,最后所有的红包都被拿走。

最后,实践完成。

分析数据

在实践过程中,服务器和客户端都将自己内部的计数器记录发往监控端,成为了日志。

我们利用简单 Python 脚本和 gnuplt 绘图工具,将实践的过程可视化,由此来验证运行过程。

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

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

图的第一区间,几个小的峰值,是 100 万客户端建立连接的, 图的第二区间是 3 万 QPS 区间,我们可以看到数据比较稳定地保持在 3 万这个区间。最后是 6 万 QPS 区间。

但是从整张图可以看到 QPS 不是完美地保持在我们希望的直线上。

这主要是以下几个原因造成的:

①当非常多 goroutine 同时运行的时候,依靠 sleep 定时并不准确,发生了偏移。

我觉得这是 Golang 本身调度导致的。当然如果 CPU 比较强劲,这个现象会消失。

②因为网络的影响,客户端在发起连接时,可能发生延迟,导致在前 1 秒没有完成连接。

③服务器负载较大时,1000M 网络已经出现了丢包现象,可以通过 ifconfig 命令观察到这个现象,所以会有 QPS 的波动。

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

和客户端相对应,服务器也存在 3 个区间,和客户端的情况很接近。但是我们看到了在大概 22:57 分,系统的处理能力就有一个明显的下降,随后又提高的尖状,这说明代码还需要优化。

整体观察可以发现,在 3 万 QPS 区间,服务器的 QPS 比较稳定,在 6 万 QSP 时候,服务器的处理就不稳定了。我相信这和我的代码有关,如果继续优化的话,还应该能有更好的效果。

将两张图合并起来:

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

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

非常稳定。

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

可以发现 3 万 QPS 区间,客户端每秒获取的红包数基本在 200 左右,在 6 万 QPS 的时候,以及出现剧烈的抖动,不能保证在 200 这个数值了。

我觉得主要是 6 万 QPS 时候,网络的抖动加剧了,造成了红包数目也在抖动。

最后是 Golang 自带的 pprof 信息,其中有 GC 时间超过了 10ms, 考虑到这是一个 7 年前的硬件,而且非独占模式,所以还是可以接受。

总结

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

如果 600 台主机每台主机可以支持 6 万 QPS,只需要 7 分钟就可以完成 100 亿次摇红包请求。

虽然这个原型简单地完成了预设的业务,但是它和真正的服务会有哪些差别呢?

我罗列了一下:

参考资料:

  • 单机百万的实践

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://techblog.cloudperf.net/2016/05/2-million-packets-per-second-on-public.html

  • @火丁笔记

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

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

【编辑推荐】

  1. IT 行业薪水:系统和数据架构师、云工程师薪资最高;增长最快的技术 K8s
  2. 2020年的13个优秀企业架构工具
  3. 什么是真正的架构设计?十年Java经验让我总结出了这些,不愧是我
  4. 手写一个静态资源中间件,加深了解服务器对文件请求的缓存策略
  5. 高性能前端架构解决方案
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

 敏捷无敌之 Gitlab CI 持续集成

敏捷无敌之 Gitlab CI 持续集成

打破运维与研发壁垒
共5章 | KaliArch

91人订阅学习

秒杀高并发白话实战

秒杀高并发白话实战

主流高并发架构
共15章 | 51CTO崔皓

59人订阅学习

网络排障一点通

网络排障一点通

网络排障及优化调整案例
共20章 | 捷哥CCIE

465人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微