“双十一”带来的压力

不知道从何而起，1111这个数字成为了我们国人心中的一个节日“购物节”，商家在这一天开开心心的打折，男男女女则在这一天快快乐乐的购物。这种全民集体狂欢式的购物对金融行业是一个巨大的挑战，短时间的高并发会带来对数据接口的巨大压力。

根据公开的数据，2015年天猫的峰值交易量已经达到了14万次/秒，而这数字在2009年仅为400次/秒。

每一笔交易背后都包含了很多操作，首先，用户需要浏览很多商品才能真正触发一次购物行为，再次，在实际交易前，需要确保库存、配送、商家优惠政策等信息，生成订单后，要执行支付接口，这是要求高度一致性和可靠性的行为，支付完成后还需要回调多个逻辑，包括积分计算、折扣返点、物流配送等。

可见对于10万/秒这个级别的交易峰值，不仅对于金融机构是个巨大的挑战，就是对以应对大并发有经验的互联网公司，都是一件不容易的事。更为紧迫的是，随着全民IOT设备的进一步普及，双十一带来的压力会越来越大，目前已经有电商平台进行了预测，今年2016的“双十一”的峰值压力会在翻5倍。在可预见的将来，完全有可能达到100万/秒交易！

应对之道

本人有幸参与过10万/秒交易量的系统，在这里也对应对“双十一”的超高并发峰值提出一些小的经验。其实，无论是“秒杀”还是“双十一”，都没有灵丹妙药，也没有说购买一个什么硬件或者运行个什么软件就可以完全解决的，一个真正能抗超高并发的金融系统，必然是由系统中每个组件的优化而成的，让每个组件都发挥出最大的威力，同时降低各个组件间的依赖和耦合，这样最终才有可能做出可靠的平台。

在应对“双十一”中，最重要的就是两个技术“缓存-cache”和“异步化-队列”。

缓存-cache

在大型系统中，cache是最常见的组件，也是降低数据库负载的最重要环节。但我们这里所讲的cache不是传统意义上的redis/memcache等系统cache组件，而是从用户端到最后数据层的所有环节的cache。也就是说，对于高并发的场景，应对的第一条准则就是为用户行为的所有环节都加上合理的cache。

业务层次

如图所示，用户访问/交易行为的起点是浏览器，所以首先要对浏览器端进行合理的cache设置，也就是对其中的页面设置的合理的过期规则，这样配合CDN端，就可以有效降低业务的访问压力，让部分元素响应直接在浏览器cache端返回。其次，虚线内展示的是业务端，业务端主要有两个组成，一个是计算资源，也就是虚拟机或者物理机，上面运行业务代码，另一个就是数据库，如MySQL/Oracle，上面存储着业务数据。

业务层输出的内容无非分成两部分内容：动态内容+静态内容。目前对于金融业务来说，有的已经使用了CDN加速，还有的没有使用，这个依赖不同的场景，对于动态居多的电商金融业务，其实对于静态内容为主的CDN加速确实没有什么特别的效果，而反而应该对数据接口进行接口加速（ADN，API Delivery Network），而接口加速需要注意的是，不要因为给接口加cache而影响了业务本身。我们的建议是可以对有所有的读类型数据接口加cache，同时cache时间设定为毫秒级，并且针对不同的接口指定不同的cache策略，这样可以有效的提高cache命中率。

根据我们实测，通过给接口加上ADN cache，可以有效提高60%的访问速度，同时降低2-3后端实际负载。

异步化-队列

应对“双十一”的另一个技术点就是异步化-队列，其实就是通过队列将一个请求/事务放入后台运行，从原来的同步阻塞模式变成异步非阻塞模式。比如，当发生抢购时，很多用户同时调用支付接口，如果不进行队列异步化，用户的数量就是支付接口的并发度，当用户过多时，就会导致支付数据库压力过大，严重可能会导致数据库服务宕机。而采用异步模式后，抢购时，用户请求进入队列处理，队列的并发度和数据库的并发能力相匹配，这样再多的用户请求也会按序进行，这样有效的保护了数据后端。

队列的用处还不只保护后端数据库的场景，在秒杀场景时，很多用户抢购一个商品，可以先将抢购请求放入队列，然后进入后台筛选处理（比如排重、按优先级排序），然后再调用实际的下单接口。进入队列后的表现，还可以产品需求有不同的模式，常见的分成两种：一种是全异步模式，即进入队列后立即返回成功，通过回调来通知调用者后面的结果；另一种是半异步方式，即进入队列后，调用者挂起，等实际执行结束后，再返回成功或者失败结果。