高并发下的抽奖优化

一. 项目思考

由于项目发起了一个抽奖活动，发起活动之前给所有用户发短信提示他们购买了我们的产品有抽奖权益。然后用户上来进入抽奖页面点击爆增，过了一会儿页面就打不开了。后面查看了下各种日志，发现了瓶颈在数据库，由于读写冲突严重，导致响应变慢，有不少连接都超时了。后面看到监控和日志留下的数据，发现负责抽奖的微服务集群qps暴涨12倍，db的qps也涨了10倍。这很明显是一个高并发下如何摆脱数据库读写，I/O瓶颈的问题。
整点开抢后瞬时巨量的请求同时涌入，即使我们Nginx端做过初步限流，整个业务逻辑校验阶段运作良好，但是系统的瓶颈就转移到其他环节：大量的读写请求，导致后面的请求全部排队等待，等前面一个update完成释放行锁后才能处理下一个请求，大量请求等待，占用了数据库的连接。一旦数据库同一时间片内的连接数被打满，就会导致这个时间片内其他后来的全部请求因拿不到连接而超时，导致访问此数据库的其他环节也出现问题，所以RT就会异常飙高
于是我们在思考着怎么优化这个高并发下的抽奖问题

二. 优化思路

听了经验丰富的师兄的经验，也借鉴了下网上的一些思路，能采用的有效措施主要是:降级，限流，缓存，消息队列。主要原则是:尽量不暴露db,把大部分请求在服务的系统上层处理了。

三. 优化细节

1. 抽奖详情页

a. 线上开启缓存
线上已写缓存逻辑，但是没有用switch开启。开启后