写在前面
上篇文章聊了聊 如何设计可落地的重构技术方案——理论篇 这篇文章主要以最近正在做的线上重构项目——乘客排队系统重构为场景，介绍一篇完整的系统重构技术方案。
详细技术方案介绍
一、背景
1、现状:
* 目前线上乘客排队性能瓶颈很明显，主要采用Redis List存储结构。随着队列中订单量增大，查询、插入、判断订单是否在队列中等操作RT指数级增长。
* 目前乘客排队架构，无法满足业务扩展需求，为支撑之后业务快速迭代，乘客排队重构迫在眉睫。
2、调研事项
* 使用Mysql存储排队信息可行性分析(线下环境压测)
* 对外接口和影响范围梳理(目前对外提供的20个左右接口分析)，
表格如下:
| 接口名称 | 接口路径 | 调用方 | QPS | RT(995) | 平均RT | 备注 |
|---|---|---|---|---|---|---|
| 入队 | /queue/enter | XXX | XXX | XXX | XXX |
二、目标
1、对外接口不变，从底层存储改造，兼容目前线上显示场景，乘客排名显示和出队解耦。
排名显示保留普通队列、渠道队列、优先队列(包含绝对优先), 按入队时间排序
出队排序因子入队时根据固定规则计算, 采用更加灵活的策略算法计算出队优先级， 出队时只需根据排序因子排序，从而间接决定出队顺序,
2、数据存储排名采用Redis有序集合，队列信息新增mysql存储，分128张表。
3、解决目前性能瓶颈问题，支持后续业务快速迭代，以及后续需求扩展。
三、整体方案
1、新老方案对比
重构前存储架构: redis: list数据结构 , key：蜂巢中心点 + 车型 + 队列类型
重构后存储架构:
排名队列: redis有序集合, key: 蜂巢中心点 + 车型 + 队列类型(为了兼容老的)
队列信息表: queue_info_xxx, mysql存储， 按蜂巢中心点 hash分表，订单号 + 车型 建联合唯一索引
部分接口新—老对比
| 接口 | 查看排名 | 是否在队列中 | 入队 | 出队 | 插队 |
|---|---|---|---|---|---|
| 重构前 | 1. 循环所有队列中所有元素，循环判断计算位置，2.查询算法组计算预估时间 | 遍历查询出队列所有元素，循环判断是否contain | 先判断是否在队列中存在，这里也会判断根据命中不同队列类型，写入redis 队列(list) 中 | 根据车型循环&多队列类型循环出队，并记录log | 权益卡插队 |
| 重构后 | 通过订单号从”队列信息表“ 中查询排队信息，存在排队记录，判断是否存在排名，若不存在排名显示M+(排名队列存在上线控制)，否则查询”排名队列“直接返回顺序 。查询算法组计算预估时间 | 直接查询"队列信息表"判断是否存在记录 | 先写入"队列信息表"，若未超过排号阈值，则写入对应"排名队列" | 更新"队列信息表"状态，若存在排名，则从排名队列中移除，并异步通知候补，并记录log | 直接通过更新队列信息表”order_by“字段 即可改变出队顺序 |
重构前瓶颈分析: 每次请求都会将队列中元素全部取出循环遍历(当排队订单量增大时，RT呈指数级增长，卖个关子，原因大家可以想想为啥？)
重构后存储架构优势: 将原来的O(n)时间复杂度，变为O(1)复杂度。
2、重构后架构图
关于队列大小统计问题:
排名未限流队列: 直接通过ZCARD获取 (O(1) 时间复杂度)
排名限流队列: 通过计数器获取总长度 (O(1)), 降级通过ZCARD获取
2）关于新增运力撮合——查询列表【橙色部分】可能存在瓶颈问题——后期优化方向有2种 可以排名前N抽离出缓冲集合 队列截断 —— 大小超过N转为其它表存储
其它流程图: 入队、出队流程图 （此处省略）
表结构设计
queue_info_[001 ~ 128] : 排队信息表 按蜂巢中线点 hash % 128 规则分表，数据按天归档
queue_manager : 排名队列管理表 主要控制是否限流状态，和蜂巢队列信息
queue_log_[001~128]: 订单入队&出队记录表，按蜂巢中线点 hash % 128 规则分表，后期再考虑归档。
详细表结构 —— 省略
四、排序字段(order_by) 设计
针对排队场景，时间越小，越在前。可以使用时间差逆序计算，公式如下: ~(-1L << 39L) & (~(毫秒级时间差))
其它规则此处省略.
五、历史队列场景兼容问题
排名显示: 普通队列、渠道队列、优先队列
订单出队: 通过权重系数不同配置，最后计算出不同排序
六、灰度方案
按城市灰度，先选小流量城市。
七、回滚方案
关闭城市灰度开关，已存在队列中数据会影响，需要迁移工具刷新数据
八、数据归档方案 & 兜底方案
数据归档: 乘客排队信息按天归档
兜底策略: 长时间(可配置)排队状态未变更(可能出现异常)，强制退出
九、数据监控&报警
乘客排队Grafana监控: 监控指标: 城市、蜂巢、车型、普通队列数、渠道队列数、优先队列数 报警: 队列数超过阈值钉钉报警
十、时间规划
方案调研的接口(20个接口)增加改造方案、责任人，进度项
| 接口名称 | 接口路径 | 调用方 | QPS | RT(995) | 平均RT | 备注 | 改造方案 | 责任人 | 进度 |
|---|---|---|---|---|---|---|---|---|---|
| 入队 | /queue/enter | XXX | XXX | XXX | XXX |
注意: 接口自测 和 CR是在开发阶段完成的，监控报警不影响测试的开发，可以在测试阶段开发。
十一、关联组
略
十二、所需资源
略
总结
重构需要考虑到细节很多，需要考虑到每一个可能出现瓶颈的地方，以及后续优化，扩展问题。
所有改动项，必须责任到个人(避免遗漏)，另外提测之前必须全部自测通过(单元测试)。
目前该方案代码开发已经基本完成，下一篇文章继续以排队系统重构为场景，将给大家聊一聊灰度阶段压测方案如何设计，敬请期待。
欢迎关注"浅谈架构"公众号，不定期分享原创技术文章，后续有机会给大家直播分享系统重构技术细节。
