百万级QPS，支撑淘宝双11需要哪些技术 _QPS

前言
又到一年双11，相信大部分同学都曾经有这个疑问：支撑起淘宝双11这么大的流量，需要用到哪些核心技术？性能优化系列的第二篇我想跟大家探讨一下这个话题。
【百万级QPS，支撑淘宝双11需要哪些技术】完整的双11链路是非常长的，我当前也没这个实力跟大家去探讨完整的链路，本文只跟大家探讨其中的一个核心环节：商品浏览。
商品浏览是整个链路中流量最大的或者至少是之一，这个大家应该不会有疑问，因为几乎每个环节都需要商品浏览。
阿里云公布的2020年双11订单创建峰值是58.3万笔/秒，而我们在下单前经常会点来点去看这个看那个的，因此商品浏览肯定至少在百万QPS级别。
废话不多说，直接开怼。

正文
1、MySQL硬抗
不知道有没有老铁想过用MySQL硬抗双11百万QPS，反正我是没有，不过我们还是用数据来说说为什么不可能这么做。
根据MySQL官方的基准测试，MySQL在通常模式下的性能如下图所示：

文章插图

当然这个数据仅供参考，实际性能跟使用的机器配置、数据量、读写比例啥的都有影响。
首先，淘宝的数据量肯定是比较大的，这个毋庸置疑，但是无论怎么分库分表，由于成本等原因，肯定每个库还是会有大量的数据。
我当前所在的业务刚好数据量也比较大，我们DBA给的建议是单库QPS尽量控制在5000左右，实际上有可能到1万也没问题，但是此时可能存在潜在风险。
DBA给的这个建议值是比较稳健保守的，控制在这个值下基本不会出问题，因此我们尽量按DBA的建议来，毕竟他们在这方面会更专业一些。
如果按照单库抗5000来算，即使多加几个从库，也就抗个十来万QPS顶天了，要抗百万QPS就根本不可能了，流量一进来，DB肯定马上跪成一片灰烬。
有同学可能会想，能不能无限加从库硬怼？
这个是不行的，因为从库是需要占用主库资源的，看过我之前MySQL面试题的同学应该知道，主库需要不断和从库进行通信，传输binlog啥的，从库多了主库会受影响，无限加从库最后的结果肯定是将主库怼挂了，我们这边的建议值是从库数量尽量不要超过20个，超了就要想其他法子来优化。

2、分布式缓存（Tair）硬抗
上分布式缓存硬抗应该是大部分老哥会想到的，我们也用数据来分析一下可行性。
阿里用的分布式缓存是自研的 Tair，不知道的可以理解为 redis 吧，对外其实也是说的 Redis 企业版。
Tair官方自称性能约为同规格社区版实例的3倍。阿里云官网上，Tair企业版性能增强-集群版当前的实例规格如下图所示：

文章插图

右下角最猛的【4096GB集群性能增强版】的QPS参考值超过6000万+，没错，我数了好几遍，就是6000万，我的龟龟，太变态了。
直接把【4096GB集群性能增强版】怼上去就解决了，还要啥优化

文章插图

。如果一个解决不了，大不了就两个嘛。
分布式缓存确实是大多数情况下抗读流量的主力，所以用Tair硬抗的方案肯定是没大问题的，但是我们需要思考下是否存在以一些细节问题，例如：

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

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

3、客户端分布式缓存
分布式缓存放在服务端，我们称之为服务端分布式缓存，但是要使用服务端分布式缓存需要上游进行RPC调用，请求量太大会带来隐患，同时带来了额外的网络请求耗时。
为了解决这个问题，我们引入客户端分布式缓存，所谓客户端分布式缓存就是将请求Tair的流程集成在SDK里，如果Tair存在数据，则直接返回结果，无需再请求到服务端。
这样一来，商品信息只要在Tair缓存里，请求到客户端就会结束流程，服务端的压力会大大降低，同时实现也比较简单，只是将服务端的Tair请求流程在SDK里实现一遍。