详细技术方案介绍

一、背景

1、现状:

* 目前线上乘客排队性能瓶颈很明显，主要采用Redis  List存储结构。随着队列中订单量增大，查询、插入、判断订单是否在队列中等操作RT指数级增长。

* 目前乘客排队架构，无法满足业务扩展需求，为支撑之后业务快速迭代，乘客排队重构迫在眉睫。

2、调研事项

* 使用Mysql存储排队信息可行性分析(线下环境压测) 

* 对外接口和影响范围梳理(目前对外提供的20个左右接口分析)，

表格如下:

二、目标

1、对外接口不变，从底层存储改造，兼容目前线上显示场景，乘客排名显示和出队解耦。

排名显示保留普通队列、渠道队列、优先队列(包含绝对优先), 按入队时间排序

出队排序因子入队时根据固定规则计算, 采用更加灵活的策略算法计算出队优先级， 出队时只需根据排序因子排序，从而间接决定出队顺序,

2、数据存储排名采用Redis有序集合，队列信息新增mysql存储，分128张表。

3、解决目前性能瓶颈问题，支持后续业务快速迭代，以及后续需求扩展。

三、整体方案

1、新老方案对比

重构前存储架构: redis: list数据结构  ,  key：蜂巢中心点 + 车型 + 队列类型

重构后存储架构:

排名队列: redis有序集合, key: 蜂巢中心点 + 车型 + 队列类型(为了兼容老的)

队列信息表:  queue_info_xxx,   mysql存储， 按蜂巢中心点 hash分表，订单号 + 车型 建联合唯一索引

部分接口新—老对比

重构前瓶颈分析: 每次请求都会将队列中元素全部取出循环遍历(当排队订单量增大时，RT呈指数级增长，卖个关子，原因大家可以想想为啥？)

重构后存储架构优势: 将原来的O(n)时间复杂度，变为O(1)复杂度。

2、重构后架构图

关于队列大小统计问题:

排名未限流队列:   直接通过ZCARD获取 (O(1)  时间复杂度)

排名限流队列: 通过计数器获取总长度 (O(1)), 降级通过ZCARD获取

2）关于新增运力撮合——查询列表【橙色部分】可能存在瓶颈问题——后期优化方向有2种 可以排名前N抽离出缓冲集合 队列截断 —— 大小超过N转为其它表存储

3、其它流程图: 入队、出队流程图 （此处省略）

4、表结构设计

queue_info_[001 ~ 128] : 排队信息表 按蜂巢中线点 hash % 128 规则分表，数据按天归档

queue_manager : 排 名队列管理表 主要控制是否限流状态，和蜂巢队列信息

queue_log_[001~128] : 订单入队&出队记录表，按蜂巢中线点  hash % 128 规则分表，后期再考虑归档。

详细表结构 —— 省略

四、排序字段(order_by) 设计

针对排队场景，时间越小，越在前。可以使用时间差逆序计算，公式如下: ~(-1L << 39L) & (~(毫秒级时间差))

其它规则此处省略.

五、历史队列场景兼容问题

排名显示:   普通队列、渠道队列、优先队列

订单出队:  通过权重系数不同配置，最后计算出不同排序

六、灰度方案

按城市灰度，先选小流量城市。

七、回滚方案

关闭城市灰度开关，已存在队列中数据会影响，需要迁移工具刷新数据

八、数据归档方案 & 兜底方案

数据归档:   乘客排队信息按天归档

兜底策略:  长时间(可配置)排队状态未变更(可能出现异常)，强制退出

九、数据监控&报警

乘客排队Grafana监控: 监控指标:  城市、蜂巢、车型、普通队列数、渠道队列数、优先队列数 报警: 队列数超过阈值钉钉报警

十、时间规划

方案调研的接口(20个接口)增加改造方案、责任人，进度项

注意: 接口自测 和 CR是在开发阶段完成的，监控报警不影响测试的开发，可以在测试阶段开发。

十一、关联组

略

十二、所需资源

略

总结

重构需要考虑到细节很多，需要考虑到每一个可能出现瓶颈的地方，以及后续优化，扩展问题。

所有改动项，必须责任到个人(避免遗漏)，另外提测之前必须全部自测通过(单元测试)。