千万级乘客排队系统重构＆压测方案——总结篇

一、 前言

发布上篇文章线上真实排队系统重构案例分享——实战篇之后，一些朋友问我们重构进度咋样了，截至目前，我们乘客排队系统重构已经上线，并且灰度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个了，重构做多了，也已经形成自己的套路和方法，方案已经很成熟了，很多细节上的坑可以避免。这里，也欢迎系统遇到瓶颈或者有重构需求，遇到困难的朋友一起交流。

欢迎关注"浅谈架构"公众号，不定期分享原创技术文章。

file