从限流削峰到性能优化,谈1号店抽奖系统架构实践
这篇文章算是我在工作的第一个年头里关于架构方面的收获与思考的一篇总结性的文章吧，感觉还是有些深度的，所以尝试投稿到InfoQ上，果真被收录了，很开心。从7月底开始动笔，中间因为各种偷懒和一些难以预料的事情拖了很久，终于填坑完毕了。回首过去的一年，还是搞了点事情的，这是一个结束，更是一个新的开始。
1.前言
抽奖是一个典型的高并发场景应用，平时流量不多，但遇到大促活动，流量就会暴增，今年的周年庆期间的日均UV就超过百万。在过去的一年里，负责过这个项目的多次重构工作，期间各种踩坑无数，就以此文当做总结，来聊聊我们是如何架构这个高并发系统吧。
2.整体设计详解
在我看来，能提高服务器应对并发的能力的方式无非两种：
- 限流削峰：通过降低实际抵达服务器的并发量，降低服务器处理压力；
- 性能优化：从前台到硬件，优化系统各方面性能，提高服务器处理能力。
接下来我们围绕这两个方面谈谈在我们系统中所做的工作和遇到的坑。
整体架构如下图:
2.1服务器层的限流削峰
一般的分布式架构中，通用的服务器层都是分为两层，一是负载均衡器，如A10，F5，nginx等，二是web服务器，如Tomcat，Jboss等。这里我们优化了两件事情。
a).防cc
负载均衡作为分布式系统的第一层，本身并没有好说的。唯一值得一提的是针对此类大流量场景，我们特意引入了防cc机制。如在nginx可以通过配置limie_req_zone限制连接指令设置用户连接数，超出的链接会返回503，这也是流量削峰的第一层。
b).Tomcat并发参数
一般Tomcat是使用默认的参数maxThreads=500，在流量没有上来之前没什么感觉，但大流量情景下很可能会抛出异常。所以这个参数需要通过性能压测后设置为合理值，比如在压测时发现并发请求超出400+后，响应速度明显变慢，后台开始出现数据库，接口等链接超时，因此可以将maxThread改为了400，限制tomcat处理量，进一步削减流量，当然如果服务器能扛住1000的并发，这个参数就可以设为1000。
2.2应用层的限流削峰
从这里开始，请求就进入应用代码中了，在这一层，我们可以通过代码来进行流量削峰工作了，主要包括信号量，用户行为识别等方式。
a）.信号量
前面谈到了通过Tomcat并发线程配置来拦截超出的流量，但这里有一个问题是超出的请求要么被阻塞，要么被直接拒绝的，不会给出响应。在客户端看到的是长时间没有响应或者请求失败，然后不断重试，我们更希望在这个时候响应一些信息，比如说直接给出提示没有中奖，通知客户端不再请求，从而提高用户体验。因此在这里我们使用了java并发包中的Semaphore，伪代码如下:
semaphore=new Semaphore(350);
if (!semaphore.tryAcquire()) {
return "error";
}
try {
execute();
} finally {
semaphore.release();
}
假设通过压测得出的Tomcat最大线程数配置为400，那这里的信号量我们可以设成350，剩下50个线程用来响应超出的请求。在这种情景下，我们可以再用800甚至1000个并发做测试，由于请求还未抵达复杂的业务逻辑中，客户端可以在短时间内收到错误响应，不会感到延迟或请求拒绝的现象。
b).用户行为识别
Tomcat及信号量进行的并发控制我称之为硬削峰，并不管用户是谁，超出设置上限直接拒绝。但我们更想做的是将非法的请求拦截掉，比如机器脚本等等，从而保证正常用户的访问，因此，在公司风控等部门同学的协助下，引入一些简单的用户行为识别。
实时人机识别:在用户请求过程中，正常用户跟机器的请求数据会有差异，如果请求数据跟实际的数据不一致，通过实时的识别，自然就可以将这个请求标识为非法请求，直接拦截。
风控列表：除了实时的人机识别，根据还可以根据一些账号或者ip平时的购物等行为进行用户画像识别出其中的黄牛，机器账号等等，维持着一个列表，对于列表中的账号可以按风险等级进行额外的拦截。
下图一个接入用户行为识别前后的一个流量对比图
可以看到，在未接入识别时流量峰值为60w ，接入识别后流量降为30w 。二者流量的峰值有一个明显的差距，达到了预先设想中的削峰效果，有效缓解的服务器峰值的并发压力。
另一个比对是，在没有接入识别时，我们一个活动数万奖品，在活动开始3秒钟就已经被抽光，而接入之后，当活动结束时刚好被抽完。
所以，如果没有行为识别的拦截，不少正常用户根本抽不到奖品，这点跟春节抢火车票是一样的场景。
c).其他规则
其他规则包括缓存中的活动限制规则等等，根据一些简单的逻辑，也起到一定作用的流量削峰。
至此，我们所有的流量削峰思路都已经解释完了，接下来是针对性能优化做的一些工作。
2.3应用层的性能优化
性能优化是一个庞大的话题，从代码逻辑，缓存，到数据库索引，从负载均衡到读写分离，能谈的事情太多了。在我们的这个高并发系统中，性能的瓶颈在于数据库的压力，这里就聊下我们的一些解决思路。
a).缓存
缓存是降低数据库压力的有效手段，我们使用到的缓存分为两块。
分布式缓存：Ycache是1号店基于MemCache二次开发的一个分布式缓存组件，我们将跟用户相关的，数据规模大的数据缓存在Ycache中，减少不必要的读写操作。
本地缓存：使用分布式缓存降低数据库压力，但仍然有一定的网络开销，对于数据量小，无需更新的一些热数据，比如活动规则，我们可以直接在web服务器本地缓存。代表性的是EhCache了，而我们那时比较直接粗暴，直接用ConcurrentHashMap造了个轮子，也能起到同样的效果。
b).无事务
对于并发的分布式系统来说，数据的一致性是一个必须考虑的问题。
在我们抽奖系统中，数据更需要保证一致，活动奖品是1台iphone，就绝不能被抽走两台。常见的做法便是通过事务来控制，但考虑到我们业务逻辑中的如下场景。
在JDBC的事务中，事务管理器在事务周期内会独占一个connection，直到事务结束。
假设我们的一个方法执行100ms，前后各有25ms读写操作，中间向其他SOA服务器做了一次RPC，耗时50ms，这就意味着中间50ms时connection将处于挂起状态。
前面已经谈到了当前性能的瓶颈在于数据库，因此这种大事务等于将数据库链接浪费一半，所以我们没有使用事务，而是通过以下两种方式保证数据的一致性。
乐观锁：在update时使用版本号的方式保证数据唯一性，比如在用户中奖后减少已有奖品数量,
update award set award_num=award_num-1,version=version+1 where id=#{id} and version=#{version} and award_num>0唯一索引：在insert时通过唯一索引保证只插入一条数据，比如建立奖品id和用户id的唯一索引，防止insert时插入多条中奖记录。
2.4 数据库及硬件
再往下就是基础层了，包括我们的数据库和更底层的硬件，之所以单独列一节，是为了聊聊我们踩的一个坑。
当时为了应对高并发的场景，我们花了数周重构，从前台服务器到后台业务逻辑用上了各种优化手段，自认为扛住每分钟几十万流量不成问题，但这都是纸上谈兵，我们需要拿数据证明，因此用JMeter做了压测。
首先是流量预估和性能目标，这个主要依据过往的数据及业务期望值，比如我们预估的流量是15w/分钟，单次请求性能指标是100ms左右，那么吞吐量指标(TPS)为为150000/60~2500tps，每次请求100ms，即并发数为250，这只是平均的，考虑活动往往最开始几秒并发量最大，所以峰值并发估计为平均值的3-5倍。
第一次我们用50个并发做压测:
压测结果简直难以置信，平均耗时超600ms，峰值轻松破1000ms，这连生产上日常流量都扛不住，我们做了这么多手段，不应该性能反而降低了，当时都有点怀疑人生了，所以我们着手开始排查原因。
首先查看日志发现数据库链接存在超时
排查发现配置的数据库链接数为30,50个线程并发情景下会不够，将最大链接数设为100.数据库链接超时问题没有了，但问题没这么简单，测试下来还是一样的结果。
然后通过VisualVM连上压测的JVM，我们查看了线程的快照。
如图，发现在几个数据库写方法以及一个RPC接口上的耗时占比最大。
所以一方面我们自己着手查原因，另一方面也推动接口提供方减少耗时。
首先是一些常规的排查手段
- 走读对应部分代码，排查是否有锁，或者严重的逻辑错误如死循环等。
- dump虚拟机内存快照，排查是否存在死锁。
- 查看sql语句及其执行计划，确保业务逻辑合理，并走到索引。
- …
当时花了两天时间毫无进展，代码上没发现任何问题，也请教了很多同事，感觉已经陷入了思维误区，然后有位同事说这不是我们程序的问题，会不会是数据库本身或者硬件问题。我们马上找了DBA的同事，查看测试数据库的执行情况，如图：
log file sync的Avg wait超过了60ms，查阅资料后了解到这种情况的原因可能有:
- 连接阻塞；
- 磁盘io瓶颈；
然后我们一看，压测环境的服务器的硬盘是一块老的机械硬盘，而其他环境早已SSD遍地了。
我们连夜把压测环境切换到了SSD，问题解决了，最后压测结果：
单机441个并发, 平均响应时间136ms，理论上能扛住19w/分钟的流量，比起第一次压测有了数十倍的提升，单机即可扛住预估流量的压力，生产上更不成问题了，可以上线了。
至此，整个抽奖系统的架构，以及我们限流削峰和调优的所有手段已经介绍完了，接下来展开下其他的优化想法和感悟吧。
3.其他优化想法
这里还有一些曾经考虑过的想法供参考，可能由于时间，不适用等原因没有做，但也是应对高并发场景的思路。
消息队列：由于抽奖一般会有个转盘效果，意味着我们不需要马上给出结果，如果引入消息队列，无疑可以有效削峰，降低服务器压力。如果说Tomcat的并发配置和信号量的硬削峰是把1000并发直接拒掉500来做到，而这种是把1000并发排队每次处理500来实现，也就是说结果上是会处理掉所有请求，相对来说更合理。类似的秒杀系统便接入了这个功能，但由于当时重构时间只有两周，评估下来时间上来不及做，因此搁置了。
异步：前面谈到了一个RPC接口占用了近50%的耗时，经过业务逻辑上的评估这个接口是可以异步的，所以如果有必要的时候这是一个可行的方案。
读写分离：主备库的同步还是有延迟的，基于一致性考虑，读写分离的方案被我们抛弃了，但在其他高并发场景，读写分离是一个比较常见的优化方案。
活动拆库：性能的瓶颈还是在数据库，如果多个活动并行，并且互不相干，我们完全可以按活动拆库，分担数据库压力，不过这次的压力还没有达到这个量。
内存数据库：数据库的IO效率影响很大，把数据库所在的机械硬盘换成SSD后有数倍性能的提升，但内存的速度更快，相关文章已经介绍到12306已经全面应用了。
升级硬件：换了SSD后性能就上来了，在未来如果有了瓶颈,可以预见的是如果硬件的有了新的发展，通过升级硬件是比较省力的方式。
4.几点思考:
警惕流量，用户量的增长：在没有引入行为识别前，看着流量的大量上涨无疑是很高兴的，但引入用户行为识别后，发现不少流量可能来自于脚本。假设我们没有做行为识别，一个普通用户，稍微慢几秒就得不到奖品，来这么两三次，估计就不会来参加你的活动了，正常用户就这么一个个流失了，这种负面影响想想就让人背后发凉。所以当看到用户量快速增长，在高兴的同时，一定要意识到其中可能的风险，引入必要风控手段，保证真正的用户的用户体验。
性能优化是系统性的问题：从前台到后台我们考虑了很多优化方式，但最后压测不通过，一头栽在了老化的硬盘上，真是一个活生生的短板理论例子，所以优化不能单单局限代码，JVM的层次，从页面到硬盘，一定要通盘考虑。在遇到性能瓶颈时，不要只从表面的代码排查问题，要深入，网络，硬件都有可能瓶颈。
5.致谢
衷心的感谢过去的一年里同事们给与的帮助与指导，特别是一起加班奋斗过的小伙伴们，这是一个结束，也是一个新的开始。
作者：初龙
原文链接:https://chulung.com/article/practice-of-yhd-lottery-system-architecture
本文由MetaCLBlog于2017-07-17 09:14:17自动同步至cnblogs
本文基于 知识共享-署名-非商业性使用-禁止演绎 4.0 国际许可协议发布，转载必须保留署名及链接。
