億級粉絲大 V 下的交易高性能架構與成本優化-張欽賢.pdf

《億級粉絲大 V 下的交易高性能架構與成本優化-張欽賢.pdf》由會員分享，可在線閱讀，更多相關《億級粉絲大 V 下的交易高性能架構與成本優化-張欽賢.pdf（21頁珍藏版）》請在三個皮匠報告上搜索。

1、億級粉絲大 V 下的交易高性能架構與成本優化快手電商/張欽賢個人介紹&演講目錄張欽賢 快手電商 技術專家負責快手電商正向交易的架構升級、穩定性保障、成本性能優化等工作，2021 年 11 月入職后成功完成多項重大項目，包括交易訂單模型升級、交易平臺化架構建設、高可用穩定性保障、白盒化成本性能優化等，將交易系統的穩定性和性能提升到電商領域第一梯隊?？焓蛛娚探灰状骎直播流量特點 快手電商交易架構面臨的核心挑戰 快手電商交易架構高性能解決方案 如何高性能高并發扣減庫存？如何高性能實現分布式事務？如何高性能管理下游依賴調用？如何設計高性能的數據訪問接口？如何在業務高速增長同時優化成本？演講目錄快手電商

2、交易大V直播流量特點快手直播電商：不定時、脈沖式超高秒殺交易流量1億+粉絲近500w人同時在線近100w每秒下單請求快手電商交易架構面臨的性能和成本挑戰1、單熱點商品庫存扣減難度大2、下單分布式事務性能要求高3、依賴服務多編排調用復雜4、業務體量增長帶來成本上升5、訂單承載信息多，模型和接口擴展性要求高架構原則&目標：保持牢固穩定性、流暢性能體驗、追求低成本快手某大V有1億+高粘性粉絲，經常推出庫存為幾百萬的1元低價商品，造成業界最高的單熱點商品扣減流量，遠大于友商交易下單需要扣減庫存等資源，然后保存訂單到數據庫，是一個典型的分布式事務問題，面臨CAP和高性能的挑戰交易依賴幾十個下游業務的上百

3、個依賴方法，依賴管理復雜性高，串行調用會導致RT累積，影響系統的穩定性和用戶體驗業務持續高速發展，隨著時間積累，數據量成指數級增長，數據量的提升也必將帶來一系列問題，例如成本升高、性能變差隨著電商業務的不斷高速發展，定制業務需求數量快速增長，交易訂單模型和數據訪問接口要求能夠快速高性能支撐各種靈活的定制邏輯快手電商交易架構針對上述挑戰的整體解決方案直播短視頻買家首頁店鋪活動流量NativeAPI網關RNH5多端入口支持精準限流模塊安全防刷單模塊交易服務購物車訂單確認下單訂單管理超時任務交易存儲訂單庫買家索引庫賣家索引庫賣家ESHive/Redis冷熱數據歸檔優化成本在線庫歷史庫定時歸檔聯合查詢

4、高性能依賴管理調用商品查詢店鋪查詢庫存扣減限購扣減營銷校驗保存訂單高性能庫存扣減Mysql庫存扣減Redis庫存扣減容災&熱點商品切換高性能分布式事務同步扣減異步回退廢單消息&數據對賬高性能可擴展的訂單模型和數據接口主子單擴展字段訂單打標按需查詢高性能API流量管理：精準流量預估&限流避免流量超限，請求排隊提供良好的限流用戶體驗，安全防刷單避免黑產攻擊高性能庫存扣減：Redis和DB容災雙活能力，最大限度保障穩定性和高性能高性能分布式事務：下單同步扣減下游資源、失敗異步回退，廢單消息保障一致性和高性能高性能下游依賴調用：下游依賴分級保障穩定性，異步調用編排實現高性能高性能訂單模型和數據接口：訂

5、單主子單模型+擴展字段靈活支持業務，按需查詢提升性能冷熱數據歸檔優化成本：在線庫數據定時同步到歷史庫，提供聯合查詢能力對業務透明請求排隊能力1、高性能高并發秒殺庫存扣減快手有1億+粉絲的大V，經常推出庫存幾百萬單的1元低價福利商品，造成業界最高的單熱點商品扣減流量，遠大于友商。日常大V沒有開播的情況下又會恢復到較低的流量，這種脈沖式流量對庫存存儲架構的穩定性、性能、一致性帶來了極大挑戰。庫存存儲方案選型優點缺點全部使用Mysql數據可靠性要高，主從切換可以做到不丟數據單key寫入能力大幅低于Redis，需要搭建從庫來支撐讀能力，成本較高全部使用Redis能支持超高的單key查詢和扣減、性能高、

6、存儲成本低在主從切換、主備切換時存在數據丟失的可能大V直播期間全部使用Redis，非高峰期使用MySQL非高峰期間不需要擔心數據丟失，高峰期間可以支撐熱點商品庫存扣減，保障下單成功率切換時，需要停寫，會影響所有商品的售賣，導致切換時間GMV跌零大V售賣熱點商品使用Redis，其他商品使用MySQL非大V售賣熱點商品不需要擔心數據丟失，大V售賣商品可以支撐熱點商品庫存扣減，保障下單成功率，切換停寫只影響部分商品售賣需要提前獲得大V售賣的熱點福利商品，通過白名單方式維護,在操作時需要對這部分商品停寫,實現邏輯會復雜出于數據可靠性、保障GMV這兩個關鍵指標，選用方案4，并對MySQL進行深度優化，將

7、單行更新能力提升至10w/s+快手交易秒殺庫存應對方案1、高性能高并發秒殺庫存扣減雙存儲優勢結合：提前獲取到大V售賣的商品id，當這些商品下單時使用Redis進行扣減，其他商品使用MySQL扣減；在處理異步消息時，如果商品為非大V售賣商品，則覆蓋Redis，如果商品為大V售賣商品，則修改MySQL。數據一致性對賬：定期全量掃描DB和Redis全量對賬，借助B端和C端的庫存變更消息，延遲核對DB和Redis數據一致性。MySQL深度優化：通過SQL合并、算子合并、鎖沖突優化等措施，深度優化MySQL，單熱點行更新能力提升至10w/s+?？焓稚碳液笈_訪問端快手開放平臺快手APP快手極速版導購場景商

8、詳導購場景管理場景小黃車提單頁下單商品管理localcachelocalcachelocalcache業務服務MySQL為主存儲鏈路Redis為主存儲鏈路讀請求寫請求寫請求讀請求庫存領域服務數據實時性要求不高的，增加localcache容災降級熱點商品秒殺RedisMySQL庫存數據MQMySQL庫存數據RedisbinlogConsumer庫存存儲2、高性能下單分布式事務傳統TCC分布式事務存在的問題1、XA兩階段提交：存儲層將事務提交分為prepare、commit兩個階段，協議簡單，但是性能較差，不適合C端大流量場景2、本地消息表/事務消息模式：將需要處理的任務通過消息的方式來異步確保執

9、行，適用于可異步執行、且后續無需回滾操作的業務流程3、最大努力通知：發起通知方通過一定的機制最大努力將業務處理結果通知到接收方，適用于業務通知類型交易下單需要扣減庫存等資源，然后保存訂單到數據庫，要么全部成功，要么全部失敗，是一個典型的分布式事務問題，面臨CAP和高性能的挑戰?？焓指＠访霘⒌膱鼍跋?，存在大量請求下單失敗，成單率甚至低于1%，對資源一致性和性能提出了更大的挑戰。庫存扣減限購扣減權益扣減營銷扣減下單同步調用正向資源扣減庫存回退限購回退權益回退營銷逆向資源回滾同步調用服務超時業務失敗系統異常下單失敗成單失敗下單失敗的一次請求中，會調用同一個服務正向扣減，逆向回退2個方法，極端情況下

10、游流量會翻倍，回退流量無差別擠占下單容量，影響下單穩定性，按照2倍擴容又會增加服務器成本分布式事務選型2、高性能下單分布式事務快手交易下單分布式事務方案庫存扣減限購扣減權益扣減營銷扣減下單同步調用正向資源扣減庫存回退限購回退權益回退營銷核銷逆向資源回滾服務超時業務失敗系統異常下單失敗成單失敗廢單消息/疑似廢單消息異步調用各個下游監聽消息資源一致性對賬訂單數據資源扣減流水廢單數據1、架構解耦資源回退解耦，避免不可預期的回退流量影響下單穩定性2、消息最終一致性下單失敗發送廢單消息/疑似廢單消息，下游監聽消息回退3、資源唯一鍵將訂單號作為資源唯一鍵，供下游記錄資源扣減流水4、資源對賬訂單、廢單、下游

11、資源扣減流水，多邊實時&離線對賬，保障一致性下單資源扣減必須是強時效性的同步調用，但是資源回退對時效性要求沒那么高，因此快手交易下單采用正向同步扣減+逆向消息異步回退的TCC分布式事務方案，保障最終一致性。3、高性能下游依賴調用交易依賴幾十個下游業務方，上百個下游方法，需要進行合理分級加固，并建立應急預案流程和快速止損修復能力，保障核心交易服務SLA 9999，最大程度減小故障影響。多級依賴管理體系強依賴有損弱依賴涉資金有損弱依賴不涉資金無損弱依賴訂單確認API下單聚合服務商品查詢庫存扣減營銷扣減限購扣減運費模板分銷信息超時信息支付行業實名加密解密用戶昵稱風控權益保障地址查詢商家信息其他聚合服

12、務同樣的治理方案下單API訂單管理API其他APINative請求H5請求小程序請求訂單API服務開關執行降級OB/CK運維平臺可視化異常數據追蹤快速修復訂單數據打標實時核對異常訂單明細數據Binlog下單數據修復平臺灰度執行修復OB/CK數據修復腳本異常數據批量執行引擎批量執行修復完成驗證數據修復結果常態化日常預案演練1、依賴管理建立多級依賴管理體系，支持故障自動降級、手動有損降級2、依賴加固配置合理的調用超時時間、限流隔板、熔斷策略，做到“拖不死、打不掛”3、故障應急建立異常數據追蹤快速修復能力，故障時降級的數據能夠快速檢索完成修復4、故障演練建立故障降級處理SOP，并配合常態化故障演練，

13、讓人人都具備故障處理能力3、高性能下游依賴調用同步調用耗時原因：RPC調用模式沒有與Netty異步線程模型對齊交易依賴上百個下游方法，如果都是同步串行調用，會導致RT累積、CPU利用率低，進而影響用戶的購買體驗；采用全異步編程又會導致代碼復雜度增高，如何在不影響代碼復雜度的前提下優化接口耗時是交易依賴調用較大的挑戰。ReactivePipeline，一個上層按照串行編碼、底層采用異步調用的依賴編排框架 上下文緩存：與傳統的Context 的區別在于，緩存的是求值過程（DataLoader）而不是值，調用下游接口的地方就不需要阻塞。依賴自編排：無需全局顯示編排，每個依賴調用任務（DataLoad

14、er）僅需聲明自身依賴即可，獲取依賴數據也無需關注值是否已經準備好。4、高性能API流量管控交易API直面用戶大流量洪峰沖擊，也是黑灰產攻擊的重災區，需要具備高性能的流量管理防控能力，既能保護后端服務不被打垮，又能有效防控搶單、刷單、爬取數據等行為，保障正常商家和用戶的權益?？焓纸灰缀诨耶a流量攔截體系快手交易多層限流體系Nginx限流服務層多維限流請求流量接口限流主調限流實例整體限流CPU自適應限流API接口限流客戶端請求排隊機制服務端限流重試機制可擴展的訂單模型設計思想：結構化+非結構化5、高性能可擴展的訂單模型和數據接口訂單作為交易最核心的模型，記錄各域關鍵數據，隨著電商業務的不斷高速發展

15、，定制業務需求數量快速增長，交易訂單模型要求能夠快速支撐各種業務的靈活定制邏輯，并提供高性能的訪問接口。通用擴展能力：設計面向各域的通用擴展結構和訂單標，快速支撐各類定制業務邏輯接入，降低研發成本，提升復用度屬性規范管控：通過擴展字段和訂單標業務規范、長度約束、申請流程等，實現有效管控，避免無序擴張訂單公共信息訂單擴展信息訂單商品信息訂單買家信息訂單賣家信息訂單優惠信息訂單履約信息營銷擴展信息是否拼團特殊玩法商品擴展信息是否預售招商類型履約擴展信息拆單發貨多段物流售后擴展信息退款狀態售后服務其他擴展信息訂單數據讀寫接口5、高性能可擴展的訂單模型和數據接口簡單查詢接口（查詢接口協議統一，與業務場

16、景無關）無狀態更新接口（更新訂單的靜態屬性，訂單屬性的變更，不會引起訂單狀態的變更）有狀態更新接口（更新訂單的狀態屬性，以及狀態相關的附加屬性，執行此操作會引起訂單狀態的流轉）接口高性能查詢實現方式：模塊化按需加載請求入參是否查詢訂單基礎信息是否查詢訂單營銷信息是否查詢訂單履約信息是否查詢訂單商家信息是否查詢訂單售后信息其他參數訂單存儲模型調用流量加載訂單基礎信息加載訂單營銷信息加載訂單履約信息加載訂單商家信息加載訂單售后信息其他返回調用上游按需序列化6、冷熱數據歸檔優化存儲成本電商業務持續高速發展，隨著時間積累，數據量成指數級增長，數據量的提升也必將帶來一系列問題存儲成本升高：存儲成本和數據

17、量成正比，數據量指數級增長帶來了存儲成本的指數級增加查詢性能下降：大量冗余數據堆積，單實例存儲空間到達TB級以后查詢性能將會急劇下滑遞延存量自然增量幾百TB/月數十PB交易大部分業務都具有冷熱數據特性，即業務數據隨著時間的推移訪問頻次會越來越低基于這一特性，可以使用數據庫歸檔策略來降低數據的存儲成本，同時提升業務對數據庫的訪問效率6、冷熱數據歸檔優化存儲成本訂單數據歸檔流程bizId訂單數讀寫詢流程歸檔規則：訂單完結后+N天后，幾乎不再有業務更新，可以歸檔歸檔流程：基于離線表掃描出所有待歸檔訂單，發送kafka消息，應用接受到消息后，對訂單加鎖，讀取數據寫入歸檔庫，刪除活躍庫，釋放鎖開始訂單讀

18、寫接口訂單號訂單庫DAO當前訂單號是否滿足歸檔規則在線庫Mapper歸檔庫Mapper在線庫歸檔庫訂單是否存在返回數據結果否是是否有可能還未結轉完成，兜底回源一次活躍庫DAO內封裝，外層調用無感知通過訂單號快速判斷是否存在于歸檔庫，DAO內封裝聯合讀寫能力，外層調用無感知，內部自動完成路由7、混合云彈性調度優化計算成本快手電商彈性容器云+阿里云的混合云模式應對秒殺，為其他業務未來借助阿里云解決資源成本優勢、快速擴縮容提供了堅實的基礎快手交易服務部署架構全量自建IDC-動態擴縮容啟用彈性混合云資源快手電商交易流量具備不定時、不可預期、脈沖式等特點，大V直播福利品秒殺下單的請求流量是日常的近100倍，這給資源部署帶來了較大挑戰，集群服務器部署少了無法應對大V不定時的搶購，部署多了又會消耗大量閑置成本?？偨Y穩定性保障、性能提升、成本優化是工程架構永遠的追求更多快手電商技術，歡迎聯系討論，掃碼關注快手技術團隊，獲取演講PPT和干貨內容