实战！如何从零搭建10万级 QPS 大流量、高并发优惠券系统--图文解析

实战！如何从零搭建10万级 QPS 大流量、高并发优惠券系统–图文解析

原文链接：https://juejin.cn/post/7087824893831544845

原文作者：字节跳动技术团队

需求背景

需要设计、开发一个能够支持十万级 QPS 的优惠券系统

什么是QPS?

Queries Per Second，意思是每秒查询率。就是每秒的查询数，对数据库而言就是数据库每秒执行的 sql 数（ insert、select、update、delete 等）

如下图：系统服务器向MySql服务器发送了一条sql，对于MySQL服务器来说，QPS为1（一秒内）

和TPS的区别：

tps（transactions per second）每秒事务数。以 commit 成功次数为准。

如下图，系统服务器中的一个请求处理向Mysql发送了2条insert和1条update,并成功执行了commit（1秒内），则对于MySQL服务器来说，TPS为1，QPS为3。

文章中提到的对MySQL的一次非事务性写入，意思就是系统服务器为了处理客户端的1次请求，向MySql只发出了1条Sql执行命令，对于MySql服务器来说(一秒内)，TPS=QPS=1

需求拆解及技术选型

需求拆解

分为两部分，券模板和券记录

券模版：管理平台或者商铺发放的优惠券 （toB）

券记录：管理客户的领券记录 (toC)

两者都开放查询接口

系统选型及中间件

存储

Mysql

缓存

Redis

作用与两方面：缓存券模板信息，在库存扣减时使用缓存。

扣减库存：高并发时，扣减库存的并发写会给Mysql数据库带来极大的IO压力

解决方案：先在缓存中扣减，定其向数据库一次性更新扣减后的库存。

表结构：

画的简单点就是：

核心逻辑

商家：

商家—登录商家后台—营销中心—优惠券发布页面—填写优惠券信息(优惠券名称、类型，面额、使用条件、有效期，优惠券数量等)

点击发布按钮后，数据库中“券模板”表中新增一条优惠券。

（本文中的重点：优惠券的库存）

客户：

客户–刷抖音–刷到直播中的店铺–店铺某个商品原价339–领取一张300元的优惠券仅售39—用户点击领券

用户点击领券后，数据库中"券发放记录"表中新增一条记录。优惠券模板表中对应的优惠券库存-1

发券：

• 发券流程分为三部分：参数校验、幂等校验、库存扣减。

上图中的幂等检查是什么意思呢？

幂等操作用于保证发券请求不正确的情况下，业务方通过重试、补偿的方式再次请求，可以最终只发出一张券，防止资金损失。

幂等简单说就是一个接口，被调用一次或者多次，返回的结果是相同的。
通俗解释就是：原文中提到的两个操作，减库存和券记录增加，无论用户点击多少次领取优惠券按钮，最终的结果都是用户只能领取一张优惠券，库存数量-1，不可以出现点几次就能领几个的这种黄牛行为。另外还存在一种情况就是网络问题，因为网络抖动，用户点击了一次但传递了两个请求到服务器。

所以图中会检测对应的参数，比如在领取记录表中检测是否已有了该用户的领取信息等。

另外上面说的重试补偿又是什么意思呢？

如下图，减库存以及券记录的数据更新不是一次完成的，而是顺序两次完成

有可能会存在这样一个问题，库存减少了，但顺序执行到券纪录+1这里时，服务突然宕机了，等于是用户领取了优惠券，库存也减少了，但由于数据库中并没有用户的券记录，用户自己查看自己的优惠券信息的时候还是看不到的。所以需要补偿用户未领的优惠券。

另外一种情况也成立，用户领取了优惠券，但库存并没有减少，也就是原文中的库存超发给平台或者商铺带来损失。

解决方案，通过MQ实现：

MQ在服务宕机重新启动时可以设置重新发送上次位置的消息。

存入消息到MQ之前，需要现在Redis中存入一个KV,用来加分布式锁以及存储状态。

大流量、高并发场景下的问题及解决方案

单个 MySQL 的每秒写入在 4000 QPS 左右，超过这个数字，MySQL 的 I/O 时延会剧量增长。

MySQL 单表记录到达了千万级别，查询效率会大大降低，如果过亿的话，数据查询会成为一个问题。

Redis 单分片的写入瓶颈在 2w 左右，读瓶颈在 10w 左右

解决方案：

MySQL分库分表

120000/4000 = 30

Redis分片

120000/20000 = 6

热点库存问题及解决方案

问题

大流量发券场景下，如果我们使用的券模板为一个，那么每次扣减库存时，访问到的 Redis 必然是特定的一个分片，因此，一定会达到这个分片的写入瓶颈，更严重的，可能会导致整个 Redis 集群不可用。

解决方案：

Redis拆库存

解决方案

热点库存的问题，业界有通用的方案：即，扣减的库存 key 不要集中在某一个分片上。如何保证这一个券模板的 key 不集中在某一个分片上呢，我们拆 key（拆库存）即可。如图：

具体的实现方式

Redis集群与一致性哈希

什么是一致性哈希？

哈希：hash,可以通过Key存储Value，也可以通过Key取得Value. 简单说就是Value存储的位置是通过Hash算法计算出来的

(实现，如HashMap)。

随着客户端发起的请求数量越来越高，为了加快响应速度，在客户端与数据库之间增加了缓存层，把数据库中的热点数据存入缓存，这样客户端可以直接从缓存取得热点数据，无需每次都访问数据库，即加快了响应时间，又降低了数据库层的压力。

hash取模运算

随着业务规模不断扩大，数据量也跟着增大，缓存数量飙增，这样就需要考据搭建缓存集群，把大量的缓存分散到多台缓存服务器中进行存储。

取模算法hash（key）%N，即：对缓存数据的key进行hash运算后取模，N是机器的数量；运算后的结果映射对应集群中的节点。具体如下图所示：

问题，如上图，三个node，所以N为3，此时key通过公式hash(key)%3存入指定节点，之后扩容成4个节点，N为4，公式也变成了hash(key)%4，之前n为3的值取不出来了。

一致性哈希

一致性哈希算法将整个哈希值空间映射成一个虚拟的圆环。整个哈希空间的取值范围为0_{2^32-1，按顺时针方向开始从0}2^{32-1排列，最后的节点2}32-1在0开始位置重合，形成一个虚拟的圆环。

对服务器IP地址进行哈希计算，哈希计算后的结果对2^{32取模，结果一定是一个0到2}32-1之间的整数。最后将这个整数映射在哈希环上，整数的值就代表了一个服务器节点的在哈希环上的位置。即：hash（服务器ip）% 2^32。

当服务器接收到数据请求时，首先需要计算请求Key的哈希值；然后将计算的哈希值映射到哈希环上的具体位置；接下来，从这个位置沿着哈希环顺时针查找，遇到的第一个节点就是key对应的节点

服务器扩容

D数据本来应该会落在node1中，由于扩容节点node4,D数据落在了node4中

服务器缩容

node4节点宕机或者移除后，数据D继续顺时针找到node1节点存储。

数据倾斜与虚拟节点

数据abcd都落在node1中，node2,node3没事干，node1压力山大。

解决方案，使用虚拟节点

hash（服务器ip）% 2^32 变更为 hash（服务器ip+随机数）% 2^32

例如：Hash(“114.211.11.141”);

变更为:

Hash(“114.211.11.141#1”);

Hash(“114.211.11.141#2”);

注意，虚拟节点只是帮助真实节点扩大获取数据的范围，并不会保存数据，所获取的数据最终还是要存储在真实节点中。

减库存的时候，会轮训每一个分片，如果这个分片有库存，就-1.

本文中的问题，所有的Key都存放在一个分片上，导致一个分片累死

拆库存后，对key后面添加后缀，把key的hash值打散到多个分片中

还有一个问题：扣减子库存，每次都是从 1 开始进行的话，那对 Redis 对应分片的压力其实并没有减轻，另外在后期很多分片已经没有库存了还要空查询很多分片，影响性能

解决方案：

轮训顺序随机，每次不一定从1开始：

[1,2,3],[2,3,1]

请求完成时将剩余的库存记录下来，将已经没有库存分片编号从集合中剔除

券模板获取失败问题及解决方案

发券的流程：查券模板（Redis）–>校验–>幂等（MySQL）–> 发券（MySQL）。在查券模板信息时，我们会请求 Redis，这是强依赖，在实际的观测中，我们会发现，Redis 超时的概率大概在万分之 2、3。因此，这部分发券请求是必然失败的。

如何解决Redis超时问题：

使用二级缓存

当然，引入了本地缓存，我们还需要在每个服务实例中启动一个定时任务来将最新的券模板信息刷入到本地缓存和 Redis 中，将模板信息刷入 Redis 中时，要加分布式锁，防止多个实例同时写 Redis 给 Redis 造成不必要的压力。

服务治理

RPC的超时设置

上游调用我们的接口却迟迟不释放，需要设置超时，500ms后，连接拒绝。

通过Grafana 实现监控与报警

限流

使用docker进行资源隔离。一个服务器中可能会运行多个项目，不同的项目需要配置这台服务器的系统环境，docker可以简单理解为一台运行在服务器中的虚拟机，项目需要的系统环境都可以在docker中进行配置，不会污染到其他项目以及服务器系统。

要在每个服务实例中启动一个定时任务来将最新的券模板信息刷入到本地缓存和 Redis 中，将模板信息刷入 Redis 中时，要加分布式锁，防止多个实例同时写 Redis 给 Redis 造成不必要的压力。

服务治理

RPC的超时设置

上游调用我们的接口却迟迟不释放，需要设置超时，500ms后，连接拒绝。

通过Grafana 实现监控与报警

限流

使用docker进行资源隔离。一个服务器中可能会运行多个项目，不同的项目需要配置这台服务器的系统环境，docker可以简单理解为一台运行在服务器中的虚拟机，项目需要的系统环境都可以在docker中进行配置，不会污染到其他项目以及服务器系统。