流程

1:通過庫存服務緩存(緩存里面不僅有位圖存儲該時間點id的位置信息還有庫存信息)的Redis獲取令牌

2:拿著令牌向訂單服務同步下單

? ? ? ? 如果有令牌就執行下面的Redis，如果沒有就直接返回

? ? ? ? 扣減Redis庫存緩存

? ? ? ? ? ? ? ? 扣減成功:繼續

? ? ? ? ? ? ? ? 扣減失敗:返回

? ? ? ? ? ? ? ? ? ? ? ? 前端重試整套流程

3:1鎖2查3更新生成訂單、本地消息表、發送消息給訂單服務扣減庫存，結果返回

1.?令牌機制 + Redis 緩存前置攔截（合理）

• 令牌本質是 “下單資格憑證”，通過庫存服務的 Redis 緩存發放（結合位圖可快速校驗座位 / 時間點的可用性），能在高并發時快速攔截無資格請求（如已售罄場次），減少下游訂單服務的壓力。
• 位圖存儲位置信息（如座位是否被占用）設計巧妙：位圖的位運算（如GETBIT判斷單個座位狀態，BITCOUNT統計剩余座位）高效且節省空間，適合體育場這類 “多位置單元” 的庫存場景。

2.?Redis 緩存扣減前置 + 失敗重試（適配高并發）

• 步驟 2 先扣減 Redis 緩存，成功后再進入訂單生成流程，本質是用 Redis 的高性能做 “第一道庫存鎖定”，避免大量無效請求打到數據庫，符合高并發場景的 “緩存優先” 原則。
• 扣減失敗讓前端重試整套流程，能應對瞬時并發沖突（如多個請求同時搶最后一個庫存），通過重試提高成功率，邏輯合理。

3.?“鎖 - 查 - 更”+ 本地消息表（保證一致性）

• 步驟 3 的 “1 鎖 2 查 3 更新” 是數據庫操作的標準防超賣邏輯：加鎖避免并發修改，查實際庫存做二次校驗，更新訂單和庫存，確保數據庫層面的數據準確性。
• 本地消息表 + 消息發送的設計，能保證 “訂單生成” 與 “庫存最終扣減” 的最終一致性（即使消息發送失敗，可通過定時任務重試），解決分布式事務問題。

本地消息表解決分布式事務