性能第三讲：百万级QPS，支撑淘宝双11需要哪些技术

又到一年双11，相信大部分同学都曾经有这个疑问：支撑起淘宝双11这么大的流量，需要用到哪些核心技术？性能优化系列的第二篇我想跟大家探讨一下这个话题。

文章目录

性能第三讲：百万级QPS，支撑淘宝双11需要哪些技术
- 1、MySQL硬抗
- Action：从库数量的推荐值？
- 2、分布式缓存（Tair）硬抗
- Action：商品中心独享集群现状
- 3、客户端分布式缓存
- 4、缓存预热
- Action：商品中心缓存预热现状
- 5、客户端本地缓存
- Action：如何做基准测试？
- 6、访问DB加锁
- Action： Guava cache限制只有一个线程去db拉数据，其余线程返回旧值
- 7、热点探测
- 8、限流
- Action：对于dubbo接口，使用sentinel限流，对于MQ消费者，使用guava rateLimiter限流
- 9、全链路压测
- Action：使用jmeter进行压测
- 10、预案
- 11、降级部分非核心功能
- 12、监控大盘
- Action：商品中心是每天早9点收到核心业务监控大盘
- 13、加机器

完整的双11链路是非常长的，我当前也没这个实力跟大家去探讨完整的链路，本文只跟大家探讨其中的一个核心环节：商品浏览。

商品浏览是整个链路中流量最大的或者至少是之一，这个大家应该不会有疑问，因为几乎每个环节都需要商品浏览。

阿里云公布的2020年双11订单创建峰值是58.3万笔/秒，而我们在下单前经常会点来点去看这个看那个的，因此商品浏览肯定至少在百万QPS级别。

1、MySQL硬抗

不知道有没有老铁想过用MySQL硬抗双11百万QPS，反正我是没有，不过我们还是用数据来说说为什么不可能这么做。

根据MySQL官方的基准测试，MySQL在通常模式下的性能如下图所示：

当然这个数据仅供参考，实际性能跟使用的机器配置、数据量、读写比例啥的都有影响。

首先，淘宝的数据量肯定是比较大的，这个毋庸置疑，但是无论怎么分库分表，由于成本等原因，肯定每个库还是会有大量的数据。

我当前所在的业务刚好数据量也比较大，我们DBA给的建议是单库QPS尽量控制在5000左右，实际上有可能到1万也没问题，但是此时可能存在潜在风险。

DBA给的这个建议值是比较稳健保守的，控制在这个值下基本不会出问题，因此我们尽量按DBA的建议来，毕竟他们在这方面会更专业一些。

如果按照单库抗5000来算，即使多加几个从库，也就抗个十来万QPS顶天了，要抗百万QPS就根本不可能了，流量一进来，DB肯定马上跪成一片灰烬。

有同学可能会想，能不能无限加从库硬怼？

这个是不行的，因为从库是需要占用主库资源的，主库需要不断和从库进行通信，传输binlog啥的，从库多了主库会受影响，无限加从库最后的结果肯定是将主库怼挂了，我们这边的建议值是从库数量尽量不要超过20个，超了就要想其他法子来优化。

Action：从库数量的推荐值？

在网上没有找到合适的公式
尽量不要超过20个，目前商品中心使用的是一主两从

2、分布式缓存（Tair）硬抗

上分布式缓存硬抗应该是大部分老哥会想到的，我们也用数据来分析一下可行性。

阿里用的分布式缓存是自研的 Tair，不知道的可以理解为 Redis 吧，对外其实也是说的 Redis 企业版。

Tair官方自称性能约为同规格社区版实例的3倍。阿里云官网上，Tair企业版性能增强-集群版当前的实例规格如下图所示：

右下角最猛的【4096GB集群性能增强版】的QPS参考值超过6000万+，没错，我数了好几遍，就是6000万，太变态了。

直接把【4096GB集群性能增强版】怼上去就解决了，还要啥优化。如果一个解决不了，大不了就两个嘛。

分布式缓存确实是大多数情况下抗读流量的主力，所以用Tair硬抗的方案肯定是没大问题的，但是我们需要思考下是否存在以一些细节问题，

例如：

分布式缓存通常放在服务端，上游通过RPC来调用获取商品信息，百万级的流量瞬间打进来，是否会直接将RPC的线程池打挂？
- dubbo线程池默认是多少呢？
缓存里的信息通常是先查询DB再写到缓存里，百万级的流量瞬间打进来，是否会直接将DB打挂？
是否存在热点商品，导致Tair单节点扛不住？

…

这些问题我们接下来一一讨论。

Action：商品中心独享集群现状

使用的是 redis.cluster true

容量：prod-redis-item 容量情况13.60GB/32.00GB(32G集群版（8节点，每个节点一主一从) 使用的是Redis4.0
- 8节点意味着，将16384个节点均分成8份，对redis key使用 CRC16 算法来计算 key 所属的槽后，得到应该路由到哪个节点
- 是不是得留一半的空间给RDB
最大连接数
- 80,000
最大私网带宽
- 768 MB/s
实例架构图（集群模式）
一主一从

3、客户端分布式缓存

分布式缓存放在服务端，我们称之为服务端分布式缓存，但是要使用服务端分布式缓存需要上游进行RPC调用，请求量太大会带来隐患，同时带来了额外的网络请求耗时。

为了解决这个问题，我们引入客户端分布式缓存，所谓客户端分布式缓存就是将请求Tair的流程集成在SDK里，如果Tair存在数据，则直接返回结果，无需再请求到服务端。

这样一来，商品信息只要在Tair缓存里，请求到客户端就会结束流程，服务端的压力会大大降低，同时实现也比较简单，只是将服务端的Tair请求流程在SDK里实现一遍。

4、缓存预热

为了解决缓存为空穿透到DB将DB打挂的风险，可以对商品进行预热，提前将商品数据加载到Tair缓存中，将请求直接拦截在Tair，避免大量商品数据同时穿透DB，打挂DB。

具体预热哪些商品了？

这个其实不难选择，将热点商品统计出来即可，例如以下几类：

1）在双11零点付款前，大部分用户都会将要买的商品放到购物车，因此可以对购物车的数据进行一个统计，将其中的热点数据计算出来即可。
2）对一些有参与优惠或秒杀活动的商品进行统计，参与活动的商品一般也会被抢购的比较厉害。
3）最近一段时间销量比较大的商品，或者浏览量比较大的商品。
4）有参与到首页活动的商品，最近一段时间收藏夹的商品等等…

淘宝背后有各种各样的数据，统计出需要预热的商品并不难。

通过预热，可以大大降低DB被穿透的风险。

Action：商品中心缓存预热现状

1、对类目树预热
2、对商品缓存预热

5、客户端本地缓存

阿里云官网的数据【4096GB集群性能增强版】的QPS参考值超过6000万+，但是这个值是在请求分布比较均匀的情况下的参考值，256个分片上每个分片二三十万这样。

通常个别分片高一点也没事，五六十万估计也ok，但是一般不能高太多，否则可能出现带宽被打满、节点处理不过来等情况，导致整个集群被打垮。

这个时候就需要祭出我们的最终神器了，也就是本地缓存。本地缓存的性能有多牛逼了，我们看下这张图。

这张图是caffeine（一个高性能Java缓存框架）官方提供的本地测试结果，并不是服务器上的测试结果。

测试运行在 MacBook Pro i7-4870HQ CPU @ 2.50GHz (4 core) 16 GB Yosemite系统，简单来说，比较一般的配置，大部分服务器配置应该都会比这个高。

在这个基准测试中， 8 线程对一个配置了最大容量的缓存进行并发读。

可以看到，caffeine支持每秒操作数差不多是1.5亿，而另一个常见的缓存框架Guava差不多也有2000多万的样子。

而在服务器上测试结果如下：

服务器配置是单插槽 Xeon E5-2698B v3 @ 2.00GHz (16 核，禁用超线程)，224 GB，Ubuntu 15.04。

可以看到caffeine在使用16线程时支持每秒操作数已经达到3.8亿次，其他的框架也基本都是千万级以上。

通过上面的数据，大家应该都明白了，本地缓存在抗读流量上理论上是无敌的。当然本地缓存有一些缺点，例如需要占用服务器的本地内存，因此通常我们只会存储少量的热点数据，严格配置好参数，控制好本地缓存的占用内存上限，避免影响服务器本身的使用。

切记，吃过亏

因此，我们会对之前的热点数据，再进行一次筛选，选出“热点中的热点”，将这些数据提前预热到本地缓存中。

可能有同学会问，如果本地缓存里的商品数据发生了变更，怎么办？

一个办法是使用类似ZK的监听方式，当本地缓存的商品发生变更时，触发更新操作，本地缓存去拉取最新数据，因为本地缓存的商品数较少，所以ZK整体压力不会太大。

另一个办法是本地缓存定期拉取最新数据，例如每隔N秒后，就主动查询一次DB，将数据更新为最新数据，具体延迟几秒，根据业务上能接受的来控制。

具体选哪种看业务的选择吧，这些被筛选进入本地缓存的数据基本都是最热的那些商品，无论是商家还是运营都心里有数，肯定在活动前会再三确认，所以出现变更的几率其实不大。

Action：如何做基准测试？

todo 参考杨晓峰的文章

6、访问DB加锁

尽管我们对热点数据进行了预热，但是我们必须考虑到可能会有这么一些缓存击穿的场景：

1）某个热点数据在缓存里失效了，大量流量瞬间打到DB，导致DB被打垮。

2）某个商品并不属于热点商品，所以并没有预热，但是在活动开始后成为热点商品，导致流量大量打到DB，DB被瞬间打垮。

等等，这些场景都可能会导致DB瞬间被打垮，DB是生命线，DB一挂就凉了，因此我们必须要有相应的措施来应对。

解决方案在之前讲缓存击穿的文章里其实提过了，就是在访问DB时加锁，保证单台服务器上对于同一个商品在同一时刻，只会有一个线程去请求DB，其他的全部原地阻塞等待该线程返回结果。

注意，这边我们是不会加分布式锁的，只会加JVM锁，因为JVM锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。这个在Guava中就有现成的实现，有兴趣的可以看看。

Action： Guava cache限制只有一个线程去db拉数据，其余线程返回旧值

7、热点探测

我们上述所说的热点商品都是基于已有数据的分析，属于静态数据，难免会有漏掉的，因此也需要有办法能实时的探测出热点数据，从而进行缓存，保护系统稳定。

8、限流

无论你想的多么齐全，真正面临线上考验的时候，经常会出现一些你没考虑到的情况，因此，我们必须要有最终的保护措施。

限流降级作为最后一道防御墙，不到万不得已我们不希望使用到他，但是我们必须做好准备，万一发生没预料到的情况，可以保证大部分用户不会受到影响。

Action：对于dubbo接口，使用sentinel限流，对于MQ消费者，使用guava rateLimiter限流

9、全链路压测

模拟双11当天的流量进行测试，系统到底能抗多少，只有压测一下才知道，同时压测出来的指标，也会作为我们设置限流值很重要的参考依据。

Action：使用jmeter进行压测

可以参考性能第一讲

10、预案

预案是指根据评估分析或经验，对潜在的或可能发生的突发事件的类别和影响程度而事先制定的应急处置方案。

简单来说就是关键时刻一键拉闸，直接切换某些功能或者关闭降级某些功能，以保障核心功能不会受到影响。

商品中心通过apollo配置

11、降级部分非核心功能

在双11高峰期将一些非核心功能进行降级，避免影响核心流程，例如我记得订单是超过几个月就不让查。

12、监控大盘

各项核心指标都需要有监控和告警，例如：缓存命中率、服务端请求QPS、DB读写QPS等等。

同时要设置合理的告警值，万一出现异常可以及时感知及时解决。

同时要有一个核心业务监控大盘，放置最核心的业务指标监控，方便大家及时了解业务核心指标情况。

Action：商品中心是每天早9点收到核心业务监控大盘

13、加机器

虽然很多人会看不起加机器解决，但是实际上加机器是必不可少的，简单粗暴，花钱就能解决。

商品：8台机器每台机器6核 10G
分类讨论：

如果这8台机器部署在不同宿主机上，那么分别享有对应的CPU、内存，带宽等
- 类似于MySQL中的分库
如果部署在相同的宿主机，只能共享CPU、内存，带宽，这样做感觉是没意义的
- 类似于MySQL中的分表