从限流削峰到性能优化，谈1号店的抽奖系统架构实践

聊聊架构 · 公众号 · 架构 · 2016-12-04 19:45

正文

由于通过压测得出的Tomcat最大线程数配置为400，这里的信号量我们设成了350，剩下50个线程用来响应超出的请求。在这种情景下，我们曾用800个并发做过测试，由于请求还未抵达复杂的业务逻辑中，客户端可以在10ms内收到错误响应，不会感到延迟或请求拒绝的现象。

b) 用户行为识别

Tomcat及信号量进行的并发控制我称之为硬削峰，并不管用户是谁，超出设置上限直接拒绝。但我们更想做的是将非法的请求拦截掉，比如脚本，黄牛等等，从而保证正常用户的访问，因此，在公司风控等部门同学的协助下，引入一些简单的用户行为识别。

实时人机识别：在用户请求过程中，我们可以得到这么一些数据，点击行为、IP、userAgent、设备码等等，将这些加密之后推送到人机识别模块，如果发现用户没有点击操作，UA，设备码等缺失或不一致，自然就可以将这个请求标识为非法请求，直接拦截。
风控列表：除了实时的人机识别，根据还可以根据一些账号或者ip平时的购物等行为进行用户画像识别出其中的黄牛，机器账号等等，维持着一个列表，对于列表中的账号可以按风险等级进行额外的拦截。

下图一个接入用户行为识别前后的一个流量对比图。

可以明显的看到，两天的同一时刻，在未接入识别时流量峰值为 60w ，接入识别后流量降为 30w 。也就意味着有人通过脚本等工具贡献了超过一半的请求量；另一个比对是，在没有接入识别时，我们一个活动数万奖品，在活动开始 3秒钟 就已经被抽光，而接入之后，当活动结束时刚好被抽完。

所以，如果没有行为识别的拦截，不少正常用户根本抽不到奖品，这点跟春节抢火车票是一样的场景。

c) 其他规则

其他规则包括缓存中的活动限制规则等等，根据一些简单的逻辑，也起到一定作用的流量削峰。

至此，我们所有的流量削峰思路都已经解释完了，接下来是针对性能优化做的一些工作。

性能优化是一个庞大的话题，从代码逻辑，缓存，到数据库索引，从负载均衡到读写分离，能谈的事情太多了。在我们的这个高并发系统中，性能的瓶颈在于数据库的压力，这里就聊下我们的一些解决思路。

a) 缓存

缓存是降低数据库压力的有效手段，我们使用到的缓存分为两块。

分布式缓存：Ycache是1号店基于Memcache二次开发的一个分布式缓存组件，我们将跟用户相关的，数据规模大的数据缓存在Ycache中，减少不必要的读写操作。
本地缓存：使用分布式缓存降低数据库压力，但仍然有一定的网络开销，对于数据量小，无需更新的一些热数据，比如活动规则，我们可以直接在web服务器本地缓存。代表性的是EhCache了，而我们那时比较直接粗暴，直接用ConcurrentHashMap造了个轮子，也能起到同样的效果。

b) 无事务

对于并发的分布式系统来说，数据的一致性是一个必须考虑的问题。