写点什么

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

2016 年 12 月 05 日

1. 前言

抽奖是一个典型的高并发场景应用,平时流量不多,但遇到大促活动,流量就会暴增,今年的周年庆期间的日均 UV 就超过百万。在过去的一年里,负责过这个项目的多次重构工作,期间各种踩坑无数,就以此文当做总结,来聊聊我们是如何架构这个高并发系统吧。

2. 整体设计详解

在我看来,能提高服务器应对并发的能力的方式无非两种:

  1. 限流削峰:通过降低实际抵达服务器的并发量,降低服务器处理压力;
  2. 性能优化:从前台到硬件,优化系统各方面性能,提高服务器处理能力。

接下来我们围绕这两个方面谈谈在 1 号店抽奖系统中所做的工作和遇到的坑。

整体架构如下图:

2.1 服务器层的限流削峰

我们的负载服务器使用的是 A10,商业的负载均衡硬件,相比 nginx,虽然花不少钱,但在使用配置等方面简单,便于维护,web 服务器自然是 Tomcat。这里我们优化了两件事情。

a). 防 cc

负载均衡作为分布式系统的第一层,本身并没有好说的。唯一值得一提的是针对此类大流量场景,我们特意引入了防 cc 机制,限制用户每分钟的最高访问次数,超出频率的请求直接拒绝,防止用户使用脚本等方式刷请求。这个在我们使用的负载均衡器 A10 上可以自行配置,如果是 nginx 也有限制连接模块可以使用,这也是流量削峰的第一层。

b).Tomcat 并发参数

我们之前线上的 Tomcat 是使用默认的参数 maxThreads=500,在流量没有上来之前没什么感觉,但大流量情景下会抛出不少异常日志。在通过性能压测后发现,在并发请求超出 400+ 后,响应速度明显变慢,后台开始出现数据库,接口等链接超时,因此将 maxThread 改为了 400,限制 tomcat 处理量,进一步削减流量。

2.2 应用层的限流削峰

从这里开始,请求就进入应用代码中了,在这一层,我们可以通过代码来进行流量削峰工作了,主要包括信号量,用户行为识别等方式。

a). 信号量

前面谈到了通过 Tomcat 并发线程配置来拦截超出的流量,但这里有一个问题是超出的请求要么被阻塞,要么被直接拒绝的,不会给出响应。在客户端看到的是长时间没有响应或者请求失败,然后不断重试,我们更希望在这个时候响应一些信息,比如说直接给出提示没有中奖,通知客户端不再请求,从而提高用户体验。因此在这里我们使用了 java 并发包中的 Semaphore,伪代码如下:

复制代码
semaphore=new Semaphore(350);
{1}
if (!semaphore.tryAcquire()) {
return "error";
}
try {
execute();
} finally {
semaphore.release();
}
{1}

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

b). 用户行为识别

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

  1. 实时人机识别: 在用户请求过程中,正常用户跟机器的请求数据会有差异,如果请求数据跟实际的数据不一致,通过实时的识别,自然就可以将这个请求标识为非法请求,直接拦截。
  2. 风控列表:除了实时的人机识别,根据还可以根据一些账号或者 ip 平时的购物等行为进行用户画像识别出其中的黄牛,机器账号等等,维持着一个列表,对于列表中的账号可以按风险等级进行额外的拦截。

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

可以明显的看到,两天的同一时刻,在未接入识别时流量峰值为60w ,接入识别后流量降为30w 。也就意味着有人通过脚本等工具贡献了超过一半的请求量;另一个比对是,在没有接入识别时,我们一个活动数万奖品,在活动开始3 秒钟就已经被抽光,而接入之后,当活动结束时刚好被抽完。所以,如果没有行为识别的拦截,不少正常用户根本抽不到奖品,这点跟春节抢火车票是一样的场景。

c). 其他规则

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

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

2.3 应用层的性能优化

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

a). 缓存

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

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

b). 无事务

对于并发的分布式系统来说,数据的一致性是一个必须考虑的问题。在我们抽奖系统中,数据更需要保证一致,活动奖品是 1 台 iphone,就绝不能被抽走两台。常见的做法便是通过事务来控制,但考虑到我们业务逻辑中的如下场景。

在 JDBC 的事务中,事务管理器在事务周期内会独占一个 connection,直到事务结束。

假设我们的一个方法执行 100ms,前后各有 25ms 读写操作,中间向其他 SOA 服务器做了一次 RPC,耗时 50ms,这就意味着中间 50ms 时 connection 将处于挂起状态。

前面已经谈到了当前性能的瓶颈在于数据库,因此这种大事务等于将数据库链接浪费一半,所以我们没有使用事务,而是通过以下两种方式保证数据的一致性。

  1. 乐观锁:在 update 时使用版本号的方式保证数据唯一性,比如在用户中奖后减少已有奖品数量,
复制代码
update award set award_num=award_num-1,version=version+1 where id=#{id} and version=#{version} and award_num>0
  1. 唯一索引:在 insert 时通过唯一索引保证只插入一条数据,比如建立奖品 id 和用户 id 的唯一索引,防止 insert 时插入多条中奖记录。

2.4 数据库及硬件

再往下就是基础层了,包括我们的数据库和更底层的硬件,之所以单独列一节,是为了聊聊我们踩的一个坑。

当时为了应对高并发的场景,我们花了数周重构,从前台服务器到后台业务逻辑用上了各种优化手段,自认为扛住每分钟几十万流量不成问题,但这都是纸上谈兵,我们需要拿数据证明,因此用 JMeter 做了压测。

首先是流量预估,我们统计了过往的数据,预估的流量是 15w/ 分钟,单次请求性能指标是 100ms 左右,因此吞吐量为 150000/60~2500tps,每次请求 100ms,即并发数为 250,这只是平均的,考虑活动往往最开始几秒并发量最大,所以峰值并发估计为平均值的 3-5 倍。

第一次我们用 50 个并发做压测:

压测结果简直难以置信,平均耗时超 600ms,峰值轻松破 1000ms,这连生产上日常流量都扛不住,我们做了这么多手段,不应该性能反而降低了,当时都有点怀疑人生了,所以我们着手开始排查原因。

首先查看日志发现数据库链接存在超时

排查发现配置的数据库链接数为 30,50 个线程并发情景下会不够,将最大链接数设为 100. 数据库链接超时问题没有了,但问题没这么简单,测试下来还是一样的结果。

然后通过 VisualVM 连上压测的 JVM,我们查看了线程的快照。

(点击放大图像)

如图,发现在几个数据库写方法以及一个 RPC 接口上的耗时占比最大。

所以一方面我们自己着手查原因,另一方面也推动接口提供方减少耗时。

首先是一些常规的排查手段

  1. 走读对应部分代码,排查是否有锁,或者严重的逻辑错误如死循环等。
  2. dump 虚拟机内存快照,排查是否存在死锁。
  3. 查看 sql 语句及其执行计划,确保业务逻辑合理,并走到索引。

当时花了两天时间毫无进展,代码上没发现任何问题,也请教了很多同事,感觉已经陷入了思维误区,然后有位同事说这不是我们程序的问题,会不会是数据库本身或者硬件问题。我们马上找了 DBA 的同事,查看测试数据库的执行情况,如图:

log file sync 的 Avg wait 超过了 60ms,查阅资料后了解到这种情况的原因可能有:

  1. 连接阻塞;
  2. 磁盘 io 瓶颈;

然后我们一看,压测环境的服务器的硬盘是一块老的机械硬盘,而其他环境早已 SSD 遍地了。我们连夜把压测环境切换到了 SSD,问题解决了,最后压测结果:单机 441 个并发, 平均响应时间 136ms,理论上能扛住 19w/ 分钟的流量,比起第一次压测有了数十倍的提升,单机即可扛住预估流量的压力,生产上更不成问题了,可以上线了。

至此,整个抽奖系统的架构,以及我们限流削峰和调优的所有手段已经介绍完了,接下来展开下其他的优化想法和感悟吧。

3. 其他优化想法

这里还有一些曾经考虑过的想法供参考,可能由于时间,不适用等原因没有做,但也是应对高并发场景的思路。

  1. 消息队列:由于抽奖一般会有个转盘效果,意味着我们不需要马上给出结果,如果引入消息队列,无疑可以有效削峰,降低服务器压力。如果说 Tomcat 的并发配置和信号量的硬削峰是把 1000 并发直接拒掉 500 来做到,而这种是把 1000 并发排队每次处理 500 来实现,也就是说结果上是会处理掉所有请求,相对来说更合理。1 号店的秒杀系统便接入了这个功能,但由于当时重构时间只有两周,评估下来时间上来不及做,因此搁置了。
  2. 异步:前面谈到了一个 RPC 接口占用了近 50% 的耗时,经过业务逻辑上的评估这个接口是可以异步的,所以如果有必要的时候这是一个可行的方案。
  3. 读写分离:主备库的同步还是有延迟的,基于一致性考虑,读写分离的方案被我们抛弃了,但在其他高并发场景,读写分离是一个比较常见的优化方案。
  4. 活动拆库:性能的瓶颈还是在数据库,如果多个活动并行,并且互不相干,我们完全可以按活动拆库,分担数据库压力,不过这次的压力还没有达到这个量。
  5. 内存数据库:数据库的 IO 效率影响很大,把数据库所在的机械硬盘换成 SSD 后有数倍性能的提升,但内存的速度更快,相关文章已经介绍到 12306 已经全面应用了。
  6. 升级硬件:换了 SSD 后性能就上来了,在未来如果有了瓶颈, 可以预见的是如果硬件的有了新的发展,通过升级硬件是比较省力的方式。

4. 几点思考

  1. 警惕流量,用户量的增长:在没有引入行为识别前,看着监控里流量十万十万的上涨无疑是很高兴的,但引入用户行为识别后,我们发现一大半的流量可能来自于脚本。假设我们没有做行为识别,一个普通用户,稍微慢几秒就得不到奖品,来这么两三次,估计就不会来参加你的活动了,正常用户就这么一个个流失了,这种负面影响想想就让人背后发凉。所以当看到用户量快速增长,在高兴的同时,一定要意识到其中可能的风险,引入必要风控手段,保证真正的用户的用户体验。
  2. 性能优化是系统性的问题:从前台到后台我们考虑了很多优化方式,但最后压测不通过,一头栽在了老化的硬盘上,真是一个活生生的短板理论例子,所以优化不能单单局限代码,JVM 的层次,从页面到硬盘,一定要通盘考虑。在遇到性能瓶颈时,不要只从表面的代码排查问题,要深入,网络,硬件都有可能瓶颈。

关于作者

文初开,开发工程师,15 年加入 1 号店,现负责 1 号店购物流程的开发工作,曾负责 1 号店会员、抽奖系统的开发工作,博客: https://chulung.com

2016 年 12 月 05 日 16:294712

评论

发布
暂无评论
发现更多内容

用 Python 实现定时自动化收取蚂蚁森林能量

Python小二

Python

架构师训练营第 1 期第 9 周作业

好吃不贵

极客大学架构师训练营

Week 8 作業

Christy LAW

MyBatis 面试题(附答案解析)

比伯

Java 大数据 编程 架构 面试

Week 8 學習總結

Christy LAW

LeetCode 热题 - 递归

哈希说

LeetCode

网络冲浪信任危机频发,区块链能否破局?

CECBC区块链专委会

区块链 征信透明

看“区块链”如何为外贸企业融资

CECBC区块链专委会

区块链 银行

Nacos实战及其源码分析

程序员Fox

Spring Cloud nacos spring cloud alibaba

Redis 分布式锁原理看这篇就够了, 循循渐进

源码兴趣圈

redis 架构 分布式 分布式锁

Week 9 作業

Christy LAW

阿里内部“新鲜出炉”手慢无!首发面试终极指南V3.0,符合一线大厂面试知识点+面试题

Java架构追梦

Java 阿里巴巴 架构 分布式 面试手册

大专学历Java开发7年,从年初被裁到四面美团点评成功上岸,闭关七个月,入职那一天我哭了!

Java架构追梦

Java 阿里巴巴 面试 美团 java架构

《使用C ++的数据结构和程序设计》限时免费下载

计算机与AI

c++

架构师训练营第 1 期 - 第九周总结

Todd-Lee

极客大学架构师训练营

区块链的新信任模式将重塑传统金融业

CECBC区块链专委会

区块链 资产流动性

架构师训练营第 1 期 - 第九周作业

Todd-Lee

极客大学架构师训练营

第五周-笔记

leo

极客大学架构师训练营

《ZooKeeper分布式过程协同技术详解》.pdf

田维常

电子书

第五周 - 作业

leo

极客大学架构师训练营

阿里大牛八年打造,编程宝典,从初学到编程进阶—深入学习—实战

马士兵老师

Java 阿里巴巴 程序员 架构 编程语言

架构师系列之6: python实现一致性hash

桃花原记

给,你们想要的内存溢出MAT排查工具

田维常

内存溢出

Spring Cloud Config 实现分布式配置中心

AI乔治

Java 架构 微服务 Spring Cloud

接口的幂等性的多重考虑,你会了吗?

moon聊技术

Java 接口

React 灵魂 23 问

局外人

Java 前端 React

数字货币钱包开发源码,多币种钱包搭建app

WX13823153201

Week 9 學習總結

Christy LAW

git使用与原理剖析及其私服搭建

程序员Fox

git

消灭微服务的坏味道 之 循环依赖

码猿外

微服务 循环依赖 坏味道

五、一致性哈希算法

Geek_28b526

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

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