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加速

　　API加速完全不同于传统CDN的链路加速，通过缓存API返回内容并结合TCP广域网优化技术，对API请求进行优化。白山API加速将每个API的response数据毫秒级缓存在全网边缘节点，节点内存中的response数据以LRU（Least Recently Used）算法交换。在“热点事件”时，最热的信息持续保存在边缘节点，当客户端访问该API时，边缘节点可直接返回结果，不必返回源站。整个架构如下：

　　API加速架构图

　　API加速服务在网络边缘节点提供对API的加速能力，包括：API返回结果缓存能力、API请求回源网络加速能力。

　　传统观点认为，动态资源（API）无法缓存，但白山提出“任何资源都可以被缓存，只是过期时间不同”。对于常见的静态资源，缓存过期时间较长；而API并非不能被缓存，只是过期时间很短。如一个查询股价的API，可设定过期时间为50毫秒；百米运动员起跑反应时间为100-200毫秒，50毫秒对于PC端或移动端的用户体验并不会造成影响。

　　没有缓存时，1秒内如有10000个用户同时访问，后端承受10000个并发；如果设置50毫秒的缓存时间，理论上可将后端并发降低到20个（1秒/50毫秒=20），后端负载降低至五百分之一，其他请求由缓存服务器直接返回给用户。

　　综上所述，白山API加速为客户提供毫秒级缓存，在不影响用户体验的前提下提高终端用户响应速度，同时降低服务端的业务负载压力。

　　API加速还支持自定义缓存规则，使其更贴近业务，包括QueryString、Header、Path三种类型，针对场景，设定如下规则：

　　GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3}，每个理财产品都有独立ID，产品信息不随用户ID和客户端随机信息变化，因此Cache key可忽略URI中参数的{$1}和{$3}，/get_fprod.php?pid={$2}就是在边缘节点存储毫秒级的Cache key。

　　缓存的过期时间如何确定呢？与业务相关，这需要对客户提供的脱敏日志进行分析，可初步设定过期时间为500毫秒，最后还需考虑RTT修正值，以适应广域网环境；RTT则由API加速服务自动捕捉并实时更新。

　　实际效果

　　通过为客户主要的瓶颈接口配置API加速服务，并在峰值时间，从以下两个维度对比API加速服务开启与关闭时的效果：

终端用户请求平均响应时间和响应码200比例

服务集群平均负载

　　最终效果如下：

　　图A

　　图B

　　图C