社区编辑申请
注册/登录
线上真实排队系统重构案例分享
开发
这篇文章主要以最近正在做的线上重构项目——乘客排队系统重构为场景,介绍一篇完整的系统重构技术方案。

详细技术方案介绍

一、背景

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转为其它表存储

3、其它流程图: 入队、出队流程图 (此处省略)

4、表结构设计

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是在开发阶段完成的,监控报警不影响测试的开发,可以在测试阶段开发。

十一、关联组

十二、所需资源

总结

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

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

责任编辑:张燕妮 来源: 浅谈架构

同话题下的热门内容

该不该将单体架构迁移到微服务?如何创建一个无代码的自助客户聊天机器人功能测试vs.非功能测试:能否非此即彼地进行选择?JMS VS Kafka:苹果与橘子之战!「芯片法案」下周签署!台积电沉默以对佩洛西,三星、SK海力士谨慎观望Java 服务 Docker 容器化优秀实践说实话,今年互联网人跳槽的逻辑变了八个流行的 Python 可视化工具包,你喜欢哪个?

编辑推荐

2017年9月编程语言排行榜:Java、C与C++三巨头还能统治排行榜多久?2017年最受欢迎的5个前端框架比较2017年11月编程语言排行榜:脚本语言怎么了?2017年3月编程语言排行榜:Swift首次进入前十最近租房有点烦!技术人如何用Python找到称心如意的“小窝”?
我收藏的内容
点赞
收藏

51CTO技术栈公众号