詳細技術方案介紹

一、背景

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是在開發階段完成的，監控報警不影響測試的開發，可以在測試階段開發。

十一、關聯組

略

十二、所需資源

略

總結

重構需要考慮到細節很多，需要考慮到每一個可能出現瓶頸的地方，以及后續優化，擴展問題。

所有改動項，必須責任到個人(避免遺漏)，另外提測之前必須全部自測通過(單元測試)。