多元化玩法，海量成交背後的核心鍊路
第八年的雙11全球狂歡節已經落下帷幕，讓人印象深刻的1207億再次創造了曆史，雙11也從此進入了千億時代。今年雙11宗旨“全球化、娛樂互動化、無線化、全管道”在活動中展現的淋漓盡緻，從狂歡城、線下vr遊戲捉貓貓、到雙11萬星璀璨的晚會，讓無數人驚歎雙11成為全民娛樂盛宴。在娛樂狂歡的同時，雙11回報消費者最直接的就是買買買，“買出新生活、買出新高度”代表了無數剁手黨的聲音，為了讓消費者買的爽、買的值，天貓也是用盡了洪荒之力，從全球精品的低價預售，到狂歡城數十億的紅包、購物券，雙11當天更是火山紅包、密令紅包雨下個不停，再到品質商品半價、下午場滿n免一，讓消費者經曆一波又一波高潮，停都停不下來。
圖1 雙11多樣的玩法
每筆剁手之旅的背後都經過了哪些産品系統的處理，瞬間的剁手快感下面又發生了什麼樣的資訊速遞，我們通過一張圖來感受。
圖2 交易核心鍊路示意圖
令人眼花缭亂的活動，背後是怎樣的體系來支撐起這樣多元化的玩法，接下來我們一層層的來解構。在每秒17.5w筆的高峰下，每筆訂單所經的鍊路衆多，如何海量的訂單有序、準确的運作，如絲般潤滑，需要完整的業務、技術架構和對高峰時刻技術的攻堅。
紅包系統面臨的業務技術挑戰及解決之道
2.1紅包發放
紅包發放需要保證精确的預算控制，即一個預算發出去的紅包的總金額不能超過其預算金額。一個預算維護在一條db記錄中，對于紅包火山等大通路量的活動，這将成為單點熱點瓶頸，同時還會導緻單表記錄多過多，資料嚴重傾斜。
預算控制因與買家無關不需要實作單元化，而使用者的紅包資訊需要實作單元化，發放不單需要考慮預算的扣減，還需要考慮預算扣減後使用者側需要盡快透出紅包。因非單元化與單元化資料分布在不同的資料庫以及機房中，這會導緻跨機房調用，引入了更多不确定性因素。
1、挑戰
如何應對單預算超過幾十萬的發放qps，以及在2秒内透出使用者獲得的紅包。為保證精确的預算控制，決定采用資料庫的方式來管理預算，而按照之前的正常優化方式，單記錄的發放qps上限不超過4百。跨機房的網絡通信也不能保證100%暢通，萬一預算扣減成功後使用者紅包資料寫入失敗了如何感覺并處理。
2、分桶方案
通過分析過往活動資料，我們将預算拆分為多個子預算，然後平均分布到多個資料庫中，并根據紅包發放請求中的使用者id路由到不同的子預算中。在子預算餘額不足時，則路由請求至主預算中。多個子預算的扣減并不會完全相等，那麼必然有一部分先發生餘額不足，是以主預算需要比子預算多配置設定一些金額。當多個預算的餘額都非常少的時候，可以進行子預算的回收動作，避免預算劃分的碎片化。
圖3 分桶方案
3、sql優化
為了提升單記錄的寫入性能，我們對寫入的sql做了優化。紅包發放的場景主要有三條sql，兩條插入語句和一條更新語句，更新語句是導緻熱點問題的根源，為了減少更新導緻的獨占鎖，我們使用将三條sql語句放在一起，僅通過一次網絡傳輸就可以到達資料庫伺服器中。同時為更新語句設定條件以保證更新後的餘額大于等于零，這樣的寫法可以做到扣減之前不用查詢預算的餘額，僅通過判斷sql傳回的錯誤碼就能識别是不是餘額不足，減少資料庫伺服器的壓力。為更新sql添加commit_on_success标簽，保證事務成功後立即送出目前事務，不用等待用戶端獲得更新結果後再次發起commit請求，減少了1次來回的網絡互動，同時記錄的獨占鎖可以立即得到釋放。為更新sql添加target_affect_row 1 标簽保證如果滿足條件的記錄不存在，事務應該失敗因不是成功并且影響的行數為零。
通過和dba的溝通，我們還采用了集團dba團隊開發的資料庫熱點更新檔，并且修改了資料庫的磁盤寫入參數，以10個事務為一個寫入機關。
4、效果
采用前述的sql優化方案後，單記錄的發放可以穩定在8千左右的 qps，摸高到大約1萬 qps。在32個庫聯合壓測的過程中，我們發現了因sequence配置設定原因導緻無法超過5萬qps，對sequence的配置設定sql采用前述的優化思想優化後，順利達到接近30萬的qps的性能。此時資料庫與應用的性能都表現都比較平穩。
2.2紅包展現
當使用者獲得紅包後，我們需要在多個透出界面中展現使用者的紅包。這些資訊将包括使用者一共有多少個紅包可用、總計金額多少，以及詳細的紅包資訊。統計這些資訊是一件比較消耗資料庫性能的事情，而擁有紅包的使用者是很可能在短時間内多次查詢這些資訊的。
為了減少資料庫的減力，很自然的方案是使用緩存，記住使用者前一次查詢的結果。而問題的焦點就轉變為了如果确定緩存應該失效，我們要在紅包的多個生命周期節點裡做關聯邏輯才能确認緩存的失效，而這樣的改動工作量會比較大，同時多次這樣的工作很可能是沒有意義的，因為使用者很可能一次也沒有看過他的紅包。因為我們每次在進行紅包狀态的更新時，都會更新gmt_modifed字段的值為目前時間，這是一個通用準則，于是我們有了如下的緩存方案：
構造緩存時，采用事務内的一緻性讀取資料庫目前時間做到緩存生成時間，如果該使用者沒有紅包資料，那麼緩存生成時間取2000年1月1日。當使用者查詢紅包資料時，我們先執行一次sql查詢傳回使用者對應紅包資料的最後更新時間，“然後比較這裡傳回的時間與緩存生成時間的關系，當使用者紅包資料的最後更新時間大于或等于緩存生成時間時，判定緩存失效。這樣的判斷方式非常準确，同時因為可以利用資料庫索引且僅傳回很少的資訊，資料庫性能消耗的并不多。
圖4 紅包查詢方案
2.3 紅包使用
紅包使用的場景需要支撐超過8萬qps的峰值。業務上的規則是一次下單最多可以10個紅包，那麼對于我們來說，将需要更新10個紅包的狀态，産生10條紅包的使用流水記錄，并且還需要産生至多10條紅包相關的業務單據。而通常的情況是使用者的一次下單行為所涉及的紅包會被全額使用。
1、sql優化
通過sql分析我們發現在紅包使用場景中資料庫花費了大量的cpu資源進行sql解析，同時一次下單涉及的sql語句也很多，有非常多的網絡消耗。而mysql并不像sqlserver等資料庫那樣支援預編譯，但好消息是mysql支援batch insert文法。于是我們可以使用batch insert的文法來優化插入性能，使用一條update sql更新多條紅包的方式來優化更新性能，然後再将些sql使用前面提到過的合并優化方案合并為一條大的sql語句發送給資料庫伺服器，減少網絡互動。假定本次使用者下單時全額使用了3個紅包，那麼可以通過一個sql将三個紅包的餘額更新為零，同時還使用了金額鎖保證紅包并沒有其它的事務并發更新。同時為更新語句添加target_affect_row 3的标簽，如果紅包已經被其它訂單在并發場景下使用，那麼它會使目前事務失敗，并且我們可以通過資料庫傳回的錯誤碼識别這一情況。
2、效果
通過前述的優化措施，在典型的場景下，資料庫伺服器的負載下降了至少50%，而且下單的整體響應時間也減少了至少50%。
2.4紅包系統可靠性保障--一緻性消息通知
前面有提到紅包的發放隻是扣減了非單元化場景的預算，然而我們還需要在預算扣減完成後寫入單元化場景的使用者紅包資料。它們處于不同的資料庫，我們需要有機制來保證它們的一緻性。除了一緻性，還有時效性的需求，因為我們需要在發放成功後2秒内就能展現使用者的紅包資料。普遍的方案使用跨庫事務架構來解決問題，但是輕量的跨庫事務方案不能做到嚴格的事務一緻性，而嚴格的跨庫事務一緻性方案顯然是相當重的，它會極大的降低性能。加上我們還有内部業務流程串連的需求，是以便産生了一緻性消息通知-hjbus。
hjbus的思想在是業務的事務中插入一條消息記錄，建立一套消息的訂閱與分發系統來支撐消息的處理。因消息記錄與業務記錄存在于同一個資料庫中，可以做到事務一緻性。消息記錄并不大，并且多個訂閱者共享同一條消息記錄，是以并不會增加過多的資料庫性能消耗。目前我們已經可以做到生成的消息在1秒内就可以消耗，是以可以保證使用者的紅包資料透出時效。
圖5 一緻性消息通知-hjbus原理示意
同時通過消息積壓的監控，我們可以及時的發現哪些消息的消費出現了問題，出現了什麼問題，保障業務各流程的完整性。在一系列的優化工作完成後，我們的紅包系統在雙11前後都表現的相當穩定。
交易系統面臨的技術挑戰以及解決之道
雙11當天交易下單峰值達到了創紀錄的17.5萬筆每秒，而每次下單都需要完成優惠的計算、紅包的使用等一系列的操作，對整個系統的調用量實際遠遠高于17.5萬每秒。如此高的并發，加上交易系統在資料上不能出任何差錯的特點，對系統的性能和穩定性方面的要求都非常之高。
3.1前置處理，提升性能和穩定性
我們的下單系統需要通路物流系統擷取運費模闆，并計算運費的價格，在以前的架構中，這需要調用遠端的一個系統，由那個系統準備好相應的資料，計算結果後傳回。這種方式會把下單的峰值帶到下遊所有的依賴系統中，也就會要求下遊依賴系統具備峰值同等級的能力，這不僅使得整體成本很高，而且下遊系統的穩定性也會影響整體下單的穩定性，在依賴關系非常複雜的交易系統中對整體穩定性帶來了很大的挑戰。
把功能前置後，需要計算運費時，下單系統無需請求一個下遊系統，而是直接通路存儲着運費模闆資料的緩存伺服器，并通過前置在下單系統中的運費計算子產品，直接在本地計算出運費。這種方式不僅減少了遠端服務調用的網絡開銷，帶來了性能的提升，同時也減少了下單系統依賴的下遊系統個數，增強了系統的穩定性。
我們對很多下遊調用采用了功能前置的架構優化，通過雙11當天的驗證，這種方式在高峰情況下表現突出。
3.2 架構更新，提升開發效率和可靠性
雙11的挑戰不僅僅是性能和穩定性，由于參與雙11的業務團隊數量越來越多，業務玩法也越來越豐富，是以直接參與到雙11業務開發的團隊個數和開發人數也越來越多。衆多的團隊和開發人員，同時在一個平台上開發，怎麼提升開發效率也是很關鍵的一個點，這關系到是否能按時完成需求的開發。
針對多團隊協同開發的場景，交易平台去年完成了架構的更新，在新tmf2架構（見圖 6）下，業務級的代碼和平台級的代碼進行分離，平台級代碼對于交易的能力進行分類、抽象并對外透出，業務方的開發團隊能力自助地利用平台提供的能力完成各自業務的定制邏輯的開發，無須依賴平台團隊介入，進而大幅度提升整體業務開發效率。
圖6 tmf2整體架構
tmf2 作為業務與平台分離的業務架構，主要通過兩大類模型（能力模型、配置模型），并基于這兩大類模型生成的配置資料來貫穿兩個業務活動主線（業務配置主線、業務運作主線），詳見圖7。
圖7 tmf2架構模型圖
通過對交易模組化、抽象和收斂，形成了交易域基礎能力層，提供了各交易需要使用的核心能力，采用功能域－》能力－》擴充點方式進行表達。
例如，在合同訂立（下單）環節歸納有十幾個功能域，比如優惠、支付、傳遞、價格、訂單、結算、稅費等。這些域裡的能力又通過擴充點的形式開放給業務方開發做定制，以适應其不同業務場景的需求。
在此基礎上還引入了産品的概念，它是包裝了多個域的能力，對業務方提供了能滿足某種業務功能的能力包，進而使得業務能直接使用，加快業務開發效率。比如預售産品。業務能力和産品，通過業務場景串聯，進而形成一個完成的業務解決方案。
在這個架構中，業務能力、産品和場景屬于平台能力，業務方的定制功能都存放于業務包中，這樣的架構可以做到業務于平台分離、業務之間隔離的效果。進而使得平台的開發人員和業務的開發人員之間互相不幹擾，而不同業務的開發人員之間也互不影響，這極大的提升了多團隊同時協作的效率，進而提升了整體的效率。
營銷系統面臨的業務技術挑戰以及解決之道
2016年雙11，營銷平台是天貓與淘系優惠系統合并後的第一個雙11，在系統性能、穩定性、資料一緻性上遇到了諸多挑戰。下文主要是闡述營銷平台系統在高性能、資料一緻性上遇到的挑戰與解決方案的實踐，最後再介紹主要的玩法“雙11購物券”從招商到交易過程中，我們的解決方案。
4.1營銷平台雙11整體架構
營銷平台包括2個交易核心系統，分别是ump（圖中紅色部分）與promotioncenter（圖中黃色部分）。
ump負責所有優惠計算、優惠在導購與交易鍊路中的透出，包含三部分：
1、ump的核心是優惠計算。例如，折扣價是多少，這筆訂單能用多少的雙11購物券，抵扣多少金額；
2、優惠規則引擎負責處理優惠與優惠之間的關系。例如，店鋪優惠券能和店鋪滿減活動疊加使用；
3、狼煙多級緩存架構負責将優惠資料根據功能、熱度等因素配置設定到多級的緩存中，同時屏蔽了不同緩存的實作。
在2016年，ump整合了天貓優惠系統，将原天貓優惠的所有功能與資料都完整的遷移到了ump中，今年雙11和去年相比，調用鍊路、資料流都發生了巨大的變化。promotioncenter是權益平台，負責權益的傳播、權益的管理。目前主要的權益包括：卡券（店鋪優惠券、店鋪紅包、商品優惠券、天貓購物券、雙11購物券等）、優酷會員等。
4.2資料一緻性實踐--通用資料對賬平台
雙11對于營銷平台的挑戰，先從資料說起。由于營銷都是在和錢打交道，錢算的不對，帶來的就是資損，是以資料的一緻性對于業務正确性來說，尤其重要。
4.2.1 資料一緻性的挑戰和目标
1、優惠資料産生與使用過程會經曆多種資料源（db、tair、vsearch等）
2、單元化部署結構導緻資料會在多個機房中存儲
3、優惠與外部如資金，搜尋等都有關聯，資料鍊路異常複雜
4、缺少主動發現和補償機制來保障資料的最終正确，可能引發投訴與資損
4.2.2我們建立的通用資料對賬平台的目标
1、抽取底層模型，形成統一的結構
2、支援多種資料源，如db與tair等，自定義對比方式
3、支援增量與全量對賬
4、業務可配置化，能快速上線，發現線上不一緻問題，以及相應處理與報警
通用資料對賬平台（datacheck，簡稱dc）整體架構
底層基于jstorm 實時流式計算架構作為運作的基礎，上層增加了任務排程管理，資料源、對賬腳本管理、監控報警管理等子產品。使用者可以通過實作簡單的對賬腳本，就可以完成資料的對賬工作。
離線對賬，通過chronus定時排程程式，掃描db或者定時拉取雲梯表的資料，将需要對賬的内容組裝成metaq消息，datacheck根據消息内容執行對應的資料對賬腳本（資料對賬需要預先在百寶箱中配置好），最終的執行結果。
實時對賬，與離線對賬的差異在于觸發的機制不同，實時對賬通過db的drc消息觸發，精衛通過消息觸發datacheck進行對賬。
4.2.3 與功能相類似的bcp的對比
4.3多級緩存架構實踐 —— 狼煙多級緩存架構
在ump整合了天貓優惠系統後，由于天貓賣家中，會有大賣家，如：貓超、當當網、優衣庫。每到大促，熱點資料成為了我們關注的問題。ump由于實時性的要求，是一個重度依賴緩存的系統。如何防止熱點資料擊穿，提升熱點資料的通路效率，我們建立了一個多級緩存架構來解決這個問題 —— 狼煙。
4.3.1 狼煙三級緩存結構
1、預熱緩存，在雙11大促裡我們是可以預測出一些熱點資料和必定極熱的賣家次元資料。這種促銷級的活動在一定的周期内是禁止編輯的，在開始的周期内将預測的熱點資料提前寫到本地緩存。在16年雙11，狼煙做到了在3分鐘内完成7千多台機器、幾個g資料的預熱。具體實作有堆内、local tair（堆外）
2、熱點緩存，存儲在應用中的活躍資料，一些無法預測買家購買行為的資料可以按照周期内qps排序，保證top熱點常駐在零點裡。我們和sentinel團隊的子矜合作，提供了初步想法，最後由子矜完成hotsensor，采用hotsensor來防止黑馬熱點的問題。
3、全量資料緩存，一般采用tair實作，支援ldb與mdb
4.3.2 狼煙特性
1、統一接口
由于不同緩存有不同的實作，接口差異性較大，在狼煙裡封裝了統一的api，業務代碼在應用時，無須關注底層實作
2、流程控制
狼煙支援在多級緩存擷取的流程上，做到細緻的控制，如各級緩存的寫操作、tair&db一體化、db限流等等
3、緩存控制
在狼煙裡可以做到任意一級緩存的可拆分，可以細粒度到隻通路某一級緩存(包括db，在狼煙裡db也是統一的一套接口，由應用提供回調）
4、預熱緩存
狼煙采用蜻蜓進行分發需要預熱的資料，采用統一的資料結構包裝預熱的資料，在單機生成資料（檔案）後，提供資料擷取接口給到蜻蜓進行分發，分發的流程如下圖
圖8 狼煙分發原理
5、熱點緩存
高峰期驅逐政策：兩小時内資料有效，在周期内針對資料通路的qps和最近通路一次時間點進行排序，排在最後面的驅逐。熱點緩存依賴了hotsensor進行熱點的計算，hotsensor針對周期内的機關時間做了一個滑動視窗。采樣視窗長度設為1.5s或2h，這個采樣視窗又被分割為20個格子。通過用一定的算法來統計這20個格子的平均滑動視窗累積平均值來進行統計
計算公式：
6、資料處理
在涉及到多級緩存時，未命中的key到下一級進行查詢，多key的情況（譬如常見的：mget、mprefixget、mprefixgets）需要組裝每次的查詢結果，去識别到每一個key。代碼量比較多且重複，在ump裡面充斥着大量的組裝傳回結果的代碼，在應用狼煙後，清理了一大批這樣的代碼，用兩三行去替換之前幾十上百行代碼，大大增加了代碼可讀性。
4.3.4 狼煙在2016雙11表現
1、預熱緩存：優惠活動資料，命中率為百分之十幾，減少到tair百分之十幾的調用量。；卡券規則資料，命中率近乎100%，應用基本不需要通路tair擷取這部分資料。
2、熱點緩存，0點峰值整體命中率為20%左右，支援單key最高40多萬的 qps通路，沒有出現擊穿緩存到db的情況。
業務中台，電商鍊路的基石
交易，營銷，資金隻是業務平台事業部的一部分功能，除此之外部門還有商品，會員，店鋪，商戶，電子憑證，lbs，資料，評價，規則和内容功能單元。單元之間無縫的銜接建構了阿裡集團電商闆塊業務的全鍊路業務支撐技術體系，除了耳熟能詳的三淘之外，還有很多新興的業務。利用了平台提供的子產品化、可視化配置的技術元件，開放服務和中繼資料來快速定制獨特的商業形态，多個管道的商業資料又通過imap技術動态歸一沉澱，為平台治理和商家多管道鋪貨提供便利。
業務平台事業部承接集團“大中台，小前台”戰略業務層部分，以支撐業務方快速，低成本創新的能力為目标。然而，業務中台并非部門一己之力來建設，集團的技術團隊都是業務中台能力的提供者，沒有團隊界限，隻有”高效實作業務”的共同目标。按照一緻的标準和協定注冊到中台，確定子產品之間的連通性，避免重複低效建設。随着業務的頻繁上線，不斷沉澱、打磨、更新能力，技術同學發現自己精心打造的能力被多個業務使用，真是莫大的鼓舞！步入良性循環的營運機制，業務實作的效率越來越高。
雙11是業務平台事業部難得一次的全員大練兵，我們用實力和勇氣證明了自己，然而我們卻願意退居幕後鍛鑄平台，支撐前端豐富多彩的繁榮生态。今天最好的成績是明天最低的要求，我們仍然保持追求極緻使用者體驗，性能，穩定的目标，用技術拓展業務邊界，為業務方提供簡單，可信賴的電商技術基礎産品，高效高品質地支援前端業務快速發展和創新，這是我們的願望，也是我們的使命！
<a href="https://mp.weixin.qq.com/s/kdm6z6v-5zqluzhrzd1yew">原文連結</a>