一、 前言
发布上篇文章线上真实排队系统重构案例分享——实战篇之后,一些朋友问我们重构进度咋样了,截至目前,我们乘客排队系统重构已经上线,并且灰度1个月了,目前已稳定运行,从目前结果来看,还是远超预期的。这篇文章主要讲一讲,乘客排队场景压测方案以及个人的一些总结。
二、 如何评估一个排队系统性能
关于排队系统压测,也是和运维同学,测试同学碰撞了挺久,大家各执己见。因为之前,也没有对排队系统性能真正的评估,没有标准。我结合目前线上场景(目前排名前10城市),分析如下:
- 1.乘客排队形成排队时机高峰期,时间段(8:00~ 10:00 18:00~19:00 21:00~23:00)
- 2.排队平均等待时间(出队时间-入队时间) 1min ~ 5min
- 3.高峰期各大城市进入排队比例(排队订单量/当天订单总量) 10% ~ 38%
由此可知,排队性能评估指标——5分钟时间窗口支持最大排队数量(取极限值5min)。
三、 压测目标
目前: 乘客排队开全国,10% ~ 38%订单进排队,我们按50%进排队计算,目前高峰期3万/QPM, 计算得:3万 * 5 * 0.5 = 7.5万
目标: 按目前订单量翻5倍目标压测,即5分钟内,支持37.5万订单同时排队
四、压测步骤
序号 | 步骤 | 观测指标 | 操作 |
01 | 下单后派单——历史流程 | 历史流程5min支持最大排队订单数量,接口QPS情况 | 关闭开关,订单排队5min取消 |
02 | 下单后派单——新流程 | 新流程5min支持最大排队订单数量,接口QPS情况 | 开启开关,订单排队5分钟取消 |
历史流程5min同时入队量到达10W订单时,接口出现大量超时异常,到达性能瓶颈。
新流程情况如下—— 5min内入队50W订单排队,无异常,此时重要接口情况如下:
接口 | 目前QPS | 压测目标 | 压测QPS | 平均RT |
入队 | 300 | 1500 | 3000 | 12ms |
出队 | 300 | 1500 | 3000 | 40ms |
是否在队列中 | 3000 | 15000 | 15000+ | 4ms |
查询排队位置 | - | - | 8500 | 8ms |
五、乘客排队重构新老对比
5min同时排队订单数量 | 单蜂巢支持最大队列数 | |
重构前 | <10W | <1000 |
重构后 | >50W | 无限制 |
重构后查询接口平均RT整体降低65%,更新接口平均RT降低40%,且无性能瓶颈,后期可水平扩展。
六、总结
本次重构开发人力只投入了2人(人力有限),开发时间只用了7天,一共20多个接口改造,3个定时任务脚本,外加后台配置管理。在时间紧,任务重的前提下,依然有条不紊地进行,后面测试阶段测试反馈bug也很少。
截至目前,主导重构项目已经有6~7个了,重构做多了,也已经形成自己的套路和方法,方案已经很成熟了,很多细节上的坑可以避免。这里,也欢迎系统遇到瓶颈或者有重构需求,遇到困难的朋友一起交流。
欢迎关注,不定期分享原创技术文章。