注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

埖堓

 
 
 

日志

 
 
关于我

雨落风尽花红, 太匆匆, 路几重, 一夜春来秋去晚来风。 月色朦, 云雾胧, 清华过尽逍遥醉苍穹。 人生路, 视不同, 自是如水若空怎能懂? 江湖泪, 是与非, 爱恨情仇流去几个冬。

网易考拉推荐

如何抵挡住100亿次请求?——沈阳华威天下科技有限公司  

2017-03-03 10:59:11|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

1. 前言


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


同时作为一个工程师看完以后又会思考,学习了这样的文章以后是否能给自己的工作带来一些实际的经验呢?所谓纸上得来终觉浅,绝知此事要躬行能否自己实践一下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分钟就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高持续时间并不会很长。


总结


从单台服务器看它需要满足下面一些条件:

  1. 支持至少100万连接用户

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

  3. 摇红包:支持每秒83个的速度下发放红包也就是说每秒有2.3万次摇红包的请求,其中83个请求能摇到红包其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后,也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块,所以我们也把要求提高一倍达到200个红包每秒的分发速度

  4. 支持用户之间发红包业务,确保收发两边的红包数目和红包内金额要一致。同样也设定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 

系统配置以及优化文档: 
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 就能自行准确发出请求了

  评论这张
 
阅读(19)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018