后端架构设计，如何扛住100亿次请求？

架构文摘 · 公众号 · 架构 · 2019-08-02 09:00

正文

请到「今天看啥」查看全文

支持用户之间发红包业务，确保收发两边的红包数目和红包内金额要一致。同样也设定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 就能自行准确发出请求了。

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

服务器QPS

服务器端的QPS相对简单，它只需要处理客户端的请求即可。但是为了客观了解处理情况，我们还需要做2件事情。

第一：需要记录每秒处理的请求数目，这需要在代码里埋入计数器。
第二：我们需要监控网络，因为网络的吞吐情况，可以客观的反映出QPS的真实数据。为此，我利用python脚本结合ethtool 工具编写了一个简单的工具，通过它我们可以直观的监视到网络的数据包通过情况如何。它可以客观的显示出我们的网络有如此多的数据传输在发生。