一天清晨，我被一个客户电话惊醒，客户异常焦急，寻问CDN能不能帮助他们解决“秒杀”的问题，他们昨天刚刚进行了“整点秒杀活动”，结果并发量过大，导致服务宕机，用户投诉。

　　为了理清思路，我问了对方三个问题：

　　（1）服务宕机的表现是什么？

　　（2）业务的基本架构什么样？

　　（3）秒杀的峰值并发到多少？

　　顺着这些线索，我们先一起还原了应用场景：

　　某电商业务架构图

　　该公司是一家P2P理财网站，常有用户在整点抢购高利率理财产品的“整点秒杀活动”。如上图所示，终端用户请求先通过前端负载均衡，然后到达运行实际电商逻辑的Web Server；再下层是运行在VM上的8台Redis，负责存储与业务相关的Cache数据，如用户Profile、理财产品信息、用户账单信息等。实际落地数据存储在MySQL中，该MySQL只进行了简单的分库分表及读写分离。

　　进行“秒杀”时，先由风控和运营人员选好理财产品，然后标记到数据库中；活动开始由产品人员放开，终端用户抢购。

　　该公司的业务主要来自移动端，平时流量较少，但“秒杀”活动时会瞬间产生大量流量，峰值并发达到10万以上（其中可能包括bot），如此大的并发主要是集中在以下两类接口：

对于理财产品的刷新接口，类似GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3}，此类接口的请求量最多，占比90%。

对于理财产品的下单接口，类似 GET /order_fprod?uid={$1}&pid={$2}&oid={$3}&sid={$4}，此类接口的请求量较少，占比不到1%，但存在大量504超时。

　　其中uid是用户ID，pid是理财产品ID，oid是订单号，sid是随着客户端用户变化的随机token标识。

　　场景解读

　　根据与客户沟通得到的场景，初步得到了以下结论：

　　（1）客户以移动业务为主，产品通过API在客户端渲染UI，产品中几乎没有静态资源，带宽流量不高，传统CDN无法达到卸载压力的作用；

　　（2）秒杀时，产生大量502/504超时请求，说明此时用户请求已超过服务端的业务承载能力，急需扩容。

　　基于以上两点，我没有建议该公司采购CDN服务，而是推荐服务扩容，但随着我方对于业务更深层次的分析，逐渐发现了一些诡异的事情。

　　“诡异”现象

　　（1） 数据库主从负载极不均衡，通过MySQL管理工具，发现主库的Query量高达80%；

　　（2）Redis Cache节点负载极不均衡，通过查看redis info发现，秒杀时，其中一台Redis请求量极大，占比达90%以上，其他Redis请求量却很低。

　　上述反常现象激起了双方技术人员的兴趣，这也许就是问题的关键！随着分析深入，第一个现象的原因浮出水面：该公司在使用数据库时，并未如某些大型电商平台一样使用数据库中间件层进行MySQL请求的路由分发，而是在业务代码端，使用语言层面的框架完成读写分离工作。这带来了两个弊端：

程序员绕过语言层框架开发，并未真正实施读写分离；

产品人员要求展现效果实时，倒逼开发人员修改业务逻辑，会牺牲读写分离，使数据都在主库读写。

　　Cache穿透示意图

　　接着，第二个现象的原因也逐渐清晰：秒杀时，大量用户访问极少数理财产品，当这几个产品的pid恰好被hash到同一个Redis上，就会导致Cache节点热点失衡，所有请求最终集中在一个Redis，而这个Redis就是业务的瓶颈！

　　对症下药

　　1. 使用数据库中间件进行读写分离以及横向扩展控制

　　使用数据库中间件可以带来诸多好处，其中最重要的是可对业务层隐藏部分数据库细节，更好地控制业务。当然，引入数据库中间层也存在明显缺点，在业务整体架构中增加一层组件，违反了“简单有效”的设计原则。对于很多互联网公司，在早期甚至中期没有数据库中间层也很正常。 但当业务发展到一定阶段，引入数据库中间层是利大于弊的。

　　基于经验，我方推荐客户使用MySQL Route，基本可以满足简单需求，如：连接复用；负载均衡；读写分离。

　　MySQL Route架构图

　　上图是MySQL Router官方架构图，可以看到，MySQL Router优势在于插件化设计，官方提供了一系列插件供使用。

　　除MySQL Router，国内还有很多开源数据库中间件可以采用，如阿里、美团等。

　　使用数据库中间层，不仅可以解决性能问题，还能在安全方面起到作用，如审计、流量限制等，甚至拦截SQL注入、劣质SQL语句等。

　　2. 使用API加速服务缓解服务端压力

　　Cache服务失衡是比较棘手的问题。“秒杀”时，用户高频访问少数几个理财产品信息，当其Cache数据恰巧分配在同一节点，大量请求会瞬间集中到一台或少数几台节点，这就是Cache服务失衡的本质原因。不仅在电商“秒杀”场景中，其他有瞬间热点访问的业务类型也会存在这个问题。以微博为例，曾因明星热点事件导致接口缓慢甚至服务宕机，归根到底也是这个原因。“爆料”的瞬间，一个微博会在短时间内海量传播，该微博ID被同时打开，所有流量会集中到一个Redis节点。

　　这个问题如何解决？首先，Cache通常以某个数据结构的key为维度进行hash存储，大量用户只访问一个或几个key时，将导致Redis Cache节点负载不均衡，这是否一定对服务产生影响，则视并发情况而定，但这是一个巨大隐患。针对这个问题，客户提出了一种解决方案：把一个理财产品的Cache数据再拆散，1个key变成多个，降低key被分配到同一Cache节点的概率。但这种方法存在很大弊端：

　　（1）需要修改代码，原本一条get请求就可以完成的逻辑，要换成多条才能拼成；

　　（2）日常所有get/set操作的时间消耗都将成倍增加，因为1%的热点事件增加99%常规操作的时间，严重违背二八法则。

　　基于以上问题，我们推荐客户使用白山云聚合CLN-X的“API加速”来解决这个问题。

　　API加速

转载请注明出处。