开发者俱乐部

标题: “双十一”高并发应对解决之道 [打印本页]

作者: jack 时间: 2016-11-11 07:49
标题: “双十一”高并发应对解决之道

　　作者简介：丛磊，白山云科技合伙人兼工程副总裁，2016年加入白山，负责云链体系的设计与构建等工作;2006年至2015年，就职于新浪，带领团队从事云相关领域技术研发工作。国内最大公有云PaaS平台SAE创始人;工信部可信云服务认证评委。
　　1 "双十一"压力
　　不知从何时起，"双十一"成为了"购物节"，这种全民狂欢式购物对金融行业是一个巨大挑战，短时间的高并发会给数据接口带来巨大压力。据悉，2015年天猫峰值交易量达到14万次/秒，而2009年仅为400次/秒。
　　用户每一笔交易背后都包含了多项操作：首先，用户浏览多个商品才触发一次购物行为;再次，实际交易前，需要确保库存、配送、商家优惠政策等信息;生成订单后，执行支付接口，要求高度一致性和可靠性;支付完成后需要回调多个逻辑，包括积分计算、折扣返点、物流配送等。
　　可见14万/秒的交易峰值，不仅对于金融机构，即便是具备丰富应对高并发经验的互联网公司，都不是一件容易的事。更为紧迫的是，随着IOT设备进一步普及，"双十一"带来的压力将越来越大，据某电商平台预测，2016年"双十一"峰值压力将再翻5倍。在可预见的未来，交易完全有可能达到100万次/秒!
　　2 应对之道
　　本人曾参与研发交易量10万/秒级别的系统，这里对如何应对超高并发提出一些建议。其实，无论是"秒杀"还是"双十一"，都没有灵丹妙药，一个真正能抗超高并发的金融系统，必然由系统中每个组件优化而成。让每个组件发挥最大威力，并对系统充分解耦，才能做出可靠的平台。
　　应对超高并发，最重要两个技术："缓存-Cache"和"异步化-队列"。
　　3 缓存- Cache
　　这里的Cache不是传统意义上的Redis/Memcache等系统Cache组件，而是从用户端到最后数据层所有环节的Cache。
　　对于高并发场景，第一条准则就是为用户行为所有环节加上合理的Cache。
　　业务层次图如下：

　　如图所示，用户访问/交易行为的起点是浏览器。首先对浏览器端进行合理的Cache设置，即对其中页面设置合理的过期规则，配合CDN端，让部分元素响应直接在浏览器Cache端返回，有效降低业务访问压力;其次，虚线内展示的是业务端，主要由两部分构成，一个是计算资源，运行业务代码;另一个是数据库，负责存储业务数据。
　　业务层输出的内容分为两部分：动态+静态。对于动态居多的电商金融业务，以静态内容为主的CDN加速没有特别效果，而应该对数据接口进行接口加速(ADN，API Delivery Network)。接口加速需要注意的是，不能因给接口加Cache而影响业务本身。我们建议对所有读类型数据接口加Cache，并将Cache时间设定为毫秒级，针对不同接口指定不同Cache策略，有效提高Cache命中率。
　　根据实测，通过加ADN Cache，可提高60%访问速度，同时降低2-3倍后端实际负载。
　　4 异步化-队列
　　异步化-队列是通过队列将请求/事务放入后台运行，从同步阻塞模式变为异步非阻塞模式。例如，抢购发生时，用户同时调用支付接口，同步阻塞模式下，用户数量即支付接口的并发度，用户过多时，支付数据库压力过大，严重时可能会导致数据库服务宕机。采用异步模式后，抢购时，用户请求进入队列处理，队列并发度与数据库并发能力相匹配，用户请求按序进行，可有效保护数据后端。
　　队列不只可以保护后端数据库。在秒杀场景，很多用户抢购一个商品，可以先将抢购请求放入队列，再进入后台筛选处理(比如排重、按优先级排序等)，最后调用实际下单接口。队列可以根据产品需求选用两种不同模式：一种是全异步模式，即进入队列后立即返回成功，通过回调通知调用者结果;另一种是半异步，即进入队列后，调用者挂起，实际执行结束后，再返回成功或者失败结果。
　　5 总结
　　应对"双十一"高并发，主要采用缓存+队列异步化，缓存的重点是每个环节，尤其是对于传统易忽略的数据接口，都要进行合理的Cache。
　　对于高并发请求，要进行异步化非阻塞处理，防止"洪水"现象，保证业务稳定有序进行。
　　我是可爱分割线

欢迎光临开发者俱乐部 (http://xodn.com/)