核心交易鏈路架構設計與演進

前言

隨著雙11進入千億時代，電商平台正在向「全球化，娛樂互動化，無線化，全渠道」發展。

為實現全民互動，電商平台會進行低價預售，狂歡紅包，購物券，紅包雨，商品半價，滿n減1等多種促銷方式。

核心交易鏈路設計

每筆剁手操作都會經歷一系列核心系統處理，如圖：

如此眼花繚亂的玩法，底層是多個核心系統的支撐，整個系統要保證在交易高峰下的海量訂單有序，準確，順滑。

預算扣減及紅包領取

紅包發放要保證精確預算控制，預算髮放的紅包總金額不能超過預算的金額。

每條預算在資料庫中是一條記錄，在高並發場景下，可能會成為單熱點瓶頸，維護過多的記錄表，可能造成數據傾斜。

預算控制和用戶無關，無需實現單元化。用戶的紅包信息則需要實現單元化，發放流程涉及到預算扣減，扣減操作後，用戶需要儘快收到紅包。

因單元化和非單元化的數據處於不同數據中心，可能造成跨機房調用，也就引入了不確定性。

所以紅包系統和預算系統需要解決高並發場景下的預算扣減和用戶收取紅包的一致性。

分桶方案

通過分析歷史數據，我們將預算拆分為多個子預算，瓶頸分配到多個資料庫中，根據紅包發放請求的userId進行路由。在子預算餘額不足時，路由到主預算中。 每個子預算的扣減並不相等，肯定有一部分子預算會出現餘額不足的情況，所以主預算要比子預算多分配一些金額。當多個子預算餘額非常少時，可以對子預算進行回收，避免預算分片的碎片化。

資料庫優化

為提升記錄表性能，需要對資料庫操作進行梳理及優化。設想這個場景主要有3條sql：

• 兩條插入語句
• 一條更新語句

更新語句是造成熱點的瓶頸，為減少更新導致的獨佔鎖，可以將3條sql合在一起，通過一次網路傳輸到達資料庫伺服器，同時在更新語句中設置餘額大於等於0的條件，這樣可以避免在扣減之前再查詢一次餘額，而僅僅通過判斷sql錯誤碼就能識別餘額是否足，減少了對資料庫的壓力。

更新語句添加commit_on_success標籤，保證事務成功後立即提交事務，不用等到客戶端獲取更新結果再發起commit，減少了一次網路交互，同時記錄的獨佔鎖可以立即釋放。

更新語句添加target_affect_row 1 標籤，保證如果滿足條件的記錄不存在，事務應該失敗，而不是返回影響行數為0。

可以將多個事務封裝成一個資料庫的寫入單位。整體優化後系統qps可以摸高到30w。

紅包展示

用戶領取紅包後需要在多個系統終端中進行紅包展示，比如領了多少紅包，金額是多少等。 統計這些會比較消耗資料庫性能，同時展示紅包也是比較高頻的需求。採用緩存可以解決這個問題，但是隨之而來的問題是緩存的失效處理。紅包本身涉及多個生命周期，到底在哪個緩解設置緩存失效是合理的呢？

在用戶的紅包每次進行狀態變更時都會更新modify_time，所以採用讀時更新緩存：

• 採用事務內一致性讀取緩存，將當前時間設置為緩存生效時間，如果用戶沒有紅包，則生效時間為2000年1月1日。
• 當查詢到用戶用紅包時，會同時查詢出紅包的最後更新時間，然後和緩存生成時間做比較，當用戶紅包數據更新時間大於緩存生成時間，則判斷緩存失效。
• 這樣可以利用資料庫索引，同時減少返回信息，對資料庫的消耗比較少。

紅包使用

在業務規則角度進行了紅包使用控制，每次只能使用10個紅包，紅包使用場景qps也很高放大到紅包系統qps是10倍。每次紅包使用需要更新10個紅包狀態，產生10條紅包使用的流水，還需要產生至多10條紅包相關的業務單據。

一次紅包使用場景涉及到大量cpu資源進行sql解析，一次下單涉及到多個sql，對網路消耗較大。我們採用batch insert語法優化插入性能，更新語句採用多條方式提升更新性能。在業務系統中生成一個大sql發送給資料庫伺服器，減少網路交互。

比如這次下單操作涉及到5個紅包，可以通過一個sql將5個紅包餘額更新為0，同時加入金額鎖保證紅包的並發更新。設置語句的target_affect_row 5標籤，如果某個紅包已經被其他訂單並發下單使用，事務會提交失敗，可以通過資料庫返回的錯誤碼識別出這一情況。

可靠性保障

上面的情況只是處理非單元化場景預算，系統需要在預算扣減之後寫入單元化的用戶數據中。兩種數據處於不同資料庫，需要保證操作的一致性。同時在紅包領取後，在1s內展示用戶紅包，這種情況一般採用跨庫事務框架來解決。 但跨庫事務不能做到嚴格的事務一致性，嚴格的事務一致會造成性能的極大下降，於是採用內部的一致性消息jbus實現。

jbus

jbus思想是業務在事務中插入一條消息記錄，建立一套消息訂閱和分發系統對消息進行處理。消息的記錄和業務記錄在一個資料庫中，可以做到事務一致性。 多個消息訂閱者可以共享一條消息記錄，因此不會增加過多的資料庫性能損耗。做到1s內消息消費，則可以保證用戶看到自己領取的紅包。

同時建立監控系統對消息擠壓進行監控，可以及時發現消息的積壓問題，同時在消費出現問題時進行流程完整性的保障。

流程前置處理

下單系統涉及到訪問物流系統獲取運費模版，計算運費價格，之前的架構會調用遠程服務，獲取計算結果，這種方式會將下單峰值帶到下游依賴的系統中，需要下游系統具備同樣的峰值承載能力，提高了整個核心鏈路的成本，同時穩定性也帶來了複雜和挑戰。

流程前置處理後，下單系統不再需要請求物流系統，而是直接訪問運費模板緩存伺服器，通過前置下單運費計算模塊在本地計算出運費，減少了對於遠程服務的調用和依賴，提升了系統性能，增強了系統穩定性。

提升開發效率（TMF2）

隨著業務玩法的越來越豐富，參與的團隊越來越多，多個團隊在一套平台開發造成的效率浪費越來越多。

為提升開發效率架構進行了升級，業務級代碼和平台級代碼分離，平台級代碼對交易相關能力進行分類抽取，抽象提取對外提供支撐服務，業務方根據團隊能力自助式定製邏輯開發，無需平台團隊介入，大幅提高開發效率。

為達到業務和平台分離的架構目的，主要通過能力模型，配置模型，所生成對配置數據貫穿業務配置主線和業務運行主線來實現。

通過對交易建模，抽象，收斂，形成了交易基礎能力層，採用功能域->能力->擴展點方式進行表達。

在下單環節中歸納十幾個功能域，優惠，支付，交付，價格，訂單，結算，稅費等，針對這些域進行能力擴展，同時開放給業務方進行定製，適應不同業務場景需求。

同時引入產品概念，將多個域能力進行整合，對業務方提供滿足業務功能的能力包，進一步提高業務研發效率。

整個架構中，業務能力，產品，場景屬於平台能力，業務方定製功能都在業務包中，這樣可以做到業務和平台分離，業務之間隔離，使得平台開發人員和業務開發人員之間互不干擾，提升整體協作和交付效率。

業務技術挑戰

營銷平台核心系統：

優惠計算系統能力：

• 優惠計算，折扣價多少，訂單可用多少購物券，抵扣多少金額
• 優惠規則引起處理優惠和優惠之間關係，商家多少優惠券可以滿減券可以疊加使用
• 多級緩存框架負責將優惠數據按照功能，熱度等因素進行多級緩存，及緩存的不同實現

交易系統和金錢打交道，稍有不慎會帶來資損，所以數據一致性和業務正確性是平台最大的挑戰。

挑戰：

• 優惠數據產生和使用經歷多個數據源，db，tair，vsearch等
• 單元化部署結構導致數據在多個機房存儲
• 優惠和外部資金，搜索關聯，業務鏈路複雜
• 缺少主動發現和補償機制來保障最終正確，可能造成客訴和資損

目標：

• 底層抽取模型，形成統一結構
• 支持多種數據源，db，tair，自定義對比方式
• 支持增量和全量對賬
• 業務可配置化，快速上線能力，線上不一致發現能力，及時處理及預警能力

實時對賬： 底層基於storm流式計算框架，上層增加調度任務管理，數據源，對賬腳本管理，監控報警管理等模塊。用戶可以通過實現簡單對賬腳本，完成數據對賬工作。實時對賬通過db的drc消息觸發。

離線對賬： 通過定時任務，掃碼db或定時拉取表數據，將需要對賬內容組成元數據消息，datacheck根據消息內容執行對應數據腳本對賬，得到最終結果。

多級緩存框架

交易相關核心鏈路每到大促時節，數據熱點都會變成最需要解決的問題。同時對於數據一致性有一定的要求，於是好的緩存系統，做好防止熱點數據擊穿，提升熱點數據訪問效率就顯得尤為重要。

三級緩存結構

• 預熱緩存，通過歷史數據可以預測出一些熱點數據，同時參與大促的活動在一定周期內是禁止編輯的，活動開始後將預熱數據提前寫到本地緩存中，實現堆內，堆外數據預熱
• 熱點緩存，存儲活動相關熱點數據，無法預測的購買行為數據可以按照周期內qps排序，保障top熱點數據常駐緩存
• 全量數據緩存，可採用tair

特點：

1. 統一不同緩存實現的介面，業務代碼無需關注底層實現
2. 多級緩存精細控制，各級緩存的寫操作，tair&db一體化，db限流等
3. 做到任意一級緩存可拆分，粒度精細到某一級緩存（包括db）
4. 數據預熱，採用統一數據結構包裝預熱數據，單機生成數據（文件）後，提供數據介面進行分發

如圖：

熱點數據緩存與驅除

兩個小時內數據有效，在周期內針對數據訪問qps和最近一次時間點進行排序，最後的驅除。 hotsensor針對周期內單位時間做滑動窗口，窗口長度採樣採用1.5s或2h，採樣窗口劃分為20個格子，通過一定演算法統計20個格子平均滑動窗口累計平均值。

hotsensor計算方式：

多級緩存場景中，某個key到下一級緩存查詢，多key時需要組裝每次查詢結果，可以進行封裝，統一代碼風格。

總結

利用平台提供模塊化，可視化配置的技術組件，開放服務和元數據來快速定製獨有商業形態，多個渠道數據進行沉澱，實現了「大中台，小前台」的業務劃分，支撐了業務的快速發展和低成本創新的目標。

作者：春哥大魔王的博客

原文：https://my.oschina.net/u/1000241/blog/3008617

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！