浅谈架构

V1

2022/06/12阅读:18主题:极客黑

线上真实排队系统重构案例分享——实战篇

写在前面

上篇文章聊了聊 <<系统重构之道——如何设计可落地的重构方案>>, 这篇文章主要以最近正在做的线上重构项目——乘客排队服务重构为场景,介绍一篇完整的重构技术方案以及落地实施——实战篇

详细技术方案介绍

一、背景

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、重构后架构图

  1. 关于队列大小统计问题:

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

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

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

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

  2. 表结构设计

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

十一、关联组

十二、所需资源

总结

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

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

目前该方案代码开发已经基本完成,下一篇文章继续以排队系统重构为场景,将给大家聊一聊灰度阶段压测方案如何设计,敬请期待。

欢迎关注"浅谈架构"公众号,不定期分享原创技术文章,后续有机会给大家直播分享系统重构技术细节。

file
file

分类:

后端

标签:

Java

作者介绍

浅谈架构
V1