从零搭建10级QPS大流量、高并发优惠卷系统--下

3.2、券模板获取失败问题及解决方案

问题

高QPS,高并发的情况下，即使我们能将接口的成功率提升0.01%，实际表现也是客观的。回看整个发券流程：查券模板（redis）-->校验--->幂等（mysql）-->发券（mysql）。在查看券模板时，我们会请求redis,这是强依赖，在实际的观测中，我们会发现，redis超时的概率在万分之2、3。因此，这部分发券请求时必然失败的。

解决方案

为了解决这部分请求成功率，提供两种思路：

一、从redis获取券模板失败时，内部进行重试；

二、将券模板信息缓存到实例的本地内存中，引入二级缓存。

内部重试可以提高一部分请求的成功率，单无法从根本上解决redis存在超时的问题，同时重试的次数也和接口响应的时长成正比。二级缓存的引入，可以从根本上避免redis超时造成的发券请求失败。

选用二级缓存方案：

引入本地缓存，还需要在每个服务实例中启动一个定时任务来讲最新的券模板信息刷入到本地缓存和redis中，将模板信息输入redis时，要加分布式锁，防止多个实例同时写redis，造成压力。

3.3、服务治理

系统开发完成后，还需通过一系列操作保证可靠运行。

1、超时设置。优惠券系统是一个PRC服务，因此我们需要设置合理的PRC超时时间，保证系统不回因为上游系统的故障而被拖垮、例如发券的接口，我们内部执行时间不超过100ms，因此接口超时我们可以设置为500ms，如果有异常请求，在500ms后，就会被拒绝，从而保障我们服务的稳定运行。

2、监控与报警。对于一些核心接口的监控、稳定性、重要数据，以及系统CPU、内存等的监控，我们会自Grafana上建立对应的可视化图表，在春节活动期间，实时观测Grafana仪表盘，以保证能够最快观测到系统异常。同时，对于一些异常情况，我们还有完善的报警机制，从而能够第一时间感知到系统异常。

3、限流。优惠券是一个底层服务，实际业务场景下会被多个上游服务所调用，因此，合理的对这些上游服务进行限流，也是保证优惠券系统本身稳定性必不可少的一环。

4、资源隔离。因为我们服务都是部署在docker集群中的，因此为了保证服务的高可用，服务部署的 集群资源尽量分布在不同物理区域上，以避免由集群导致的服务不可用。

3.4、系统压测及实际表现

新服务上线前，首先需要进行服务压测。

注意事项

首先压测思路，由于我们一开始无法去顶docker的瓶颈，存储组件的瓶颈。所以一般思路为：

1、找到单实例瓶颈

2、找到mysql一主的写瓶颈、读瓶颈

3、找到redis单分片写瓶颈、读瓶颈

得到上述数据后，我们就可以错略估算所需要的资源数，进行服务整体压测了。

1.压测资源也很重要，提前申请到足量的压测资源，才能合理指定压测计划。

2.压测过程中，要注意服务和资源监控，对不符合预期的部分要深入思考，优化代码。

3.适时记录压测数据，更好的复盘。

4.实例的使用资源蚂蚁搬压测数据的1.5倍，我们需要保证线上有部分资源冗余以适应对突发的流量增长。

3.5结论

系统在13wQPS的发券请求下，请求成功率达到99.9%，系统监控正常。春节红包雨期间，该优惠券系统承载了两次红包雨的全部流量，期间为出现异常圆满完成发放优惠券任务。

业务系统思考

目前系统，只是单纯支持了高并发的发券功能，对于券的业务探索并不足够。后续需要结合业务，尝试批量发券（券包）、批量核销等功能。

发券系统只是一个最底层的业务中台，可以适配各种场景，后续可以探索支持更多业务，从零搭建一个大流量，高并发的优惠券系统，首先应该充分理解业务需求，然后对需求进行拆解，根据拆解后需求，合理选用各种中间件。

该优惠券系统系统，应用了各类存储组件和消息队列，来完成优惠券存储，查询，过期操作。在系统开发实现过程中，对核心的发券，券过期，实现流程进行了阐述，并针对大流量，高并发场景下可能遇到的存储瓶颈，热点库存，券模板缓存获取超时的问题提出了对应的解决方案。其中，我们使用了分治思想，对存储中间件进行水平扩容以解决存储哦情景，采取库存拆分子库思路解决热点库存问题，引入本地缓存解决券模板从redis获取超时的问题，我们还从服务超时设置，监控报警，限流，资源隔离等方面对服务进行了治理，保证服务的高可用。

压测是一个新服务不可避免的环节，通过压测我们能够对服务整体情况有个明确的了解，并且压测期间暴露的问题也会是线上可能遇到的，通过压测，我们能够对新服务的整体情况做到心中有数，对服务上线正式投产就更有信心。