歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐干貨哦~
1. 活動數據
截止3月1日手Q運動紅包會員禮包發放核銷數據
參與紅包活動用戶數：2億+
發券峰值:52w/min
2. 需求背景
2.1 紅包類型
2018年手Q春節紅包主打“走運紅包“，活動規則為除夕為參與用戶隨機派發4個業務禮包，大年初一、初二、初三用戶每走100步即可抽取一個紅包，會員這邊是按禮包給用戶發放抵扣券，其中一個禮包內有三種不同面額的抵扣券，同時上線對接了米大師IOS抵扣券平台支持了IOS終端下領券、用券、核銷券功能。
會員春節禮包活動頁面：
2.2 活動目標
整個春節期間活動產品配置發放3億個紅包
2.3 活動預估請求峰值
錢包側評估紅包領取峰值預計 5w/s
2.4 后台需求
-
支持禮包券類型發貨（3億）
后台在當前抵扣券基礎上新增禮包券類型，對外只暴露禮包ID，外部發貨傳入禮包ID和對應的終端系統平台，內部自動映射禮包內多張抵扣券，並將多張抵扣券發放到用戶卡包賬戶下。 -
支持android \ ios雙平台發券（之前只支持android平台），ios平台支持發券、用券、核銷全流程
在當前物品系統基礎上接入米大師IOS抵扣券平台，完善ios發券、支付、核銷、查券全流程，通過接入ios平台券 -
支持對跨平台使用券用戶補發對應平台券（不限制領券平台和用券平台的唯一性）
用戶抽中紅包的平台和真正用券的平台可能不一致，但是我們給用戶發什么類型的抵扣券是在用戶抽到紅包的那一刻就已經決定，這樣當用戶切換平台去支付用券就會得到“無適用抵扣券”的提示，為了不影響用戶體驗，經過團隊內部討論決定給這類需求的用戶后台靜默補發一套對應平台的券，讓用戶領到紅包在任意平台皆可支付使用。 -
支持按禮包核銷錢包側數據
用戶刷到紅包在錢包側狀態為“未領取”狀態，用戶點擊領取即可進入“已領取”狀態，進入引導用戶“去使用”，在用戶未全部使用禮包內部抵扣券之前，狀態都會停了在“未使用”的狀態，直到全部核銷使用為止 -
支持IAP凍結券回滾
主要用於支付挽留業務，在用戶放棄支付場景下對抵扣券靜默回滾操作
3. 系統架構
整體系統是在2017年架構的基礎上進行改造擴展，TGW + QZHTTP + RocketMQ + SPP邏輯服務架構 , 邏輯服務主要包括CGI代理、紅包代理（MQ生產）、紅包派發（MQ消費）、后端發貨為物品系統。存儲主要為CMEM、RocketMQ。其中紅包入口機器均為多機房接入。
4. 系統容災、高可用策略
為應對大流量高並發場景下的故障突發不確定性，我們主要從多節點接入、限流保護、熔斷降級、快速失敗、緩存加速、業務防重等幾個方面設計思考
4.1多機房部署
- 紅包入口集群、CMEM多機房部署
由於紅包流量入口大，對CGI層和紅包接入代理層的可用性要求極高，避免因機房網絡等物理故障導致集群整體不可用，在接入代理層多機房部署
4.2 限流保護&流量清洗
-
接入層流量清洗
春節紅包活動中流量大並且集中，接入代理處於系統前置邏輯，為保護后端發貨系統，有必要避免用戶重復領取請求和其他無效請求對后端系統的沖擊影響正常紅包的發放，除了基礎的請求安全校驗邏輯外在紅包接入層增加用戶紅包領取狀態存儲，春節期間削減 4kw無效請求。 -
限速保護
業務壓測評估后端發貨性能在1w/s左右，而請求峰值評估會在5w/s，在增加MQ緩沖隊列的同時還需要通過接入限速組件（限流服務優先、本地限速備用），控制消息消費速度來保護后端發貨系統，增加后端故障降級的可控性。
4.3多重防重機制
春節紅包系統中無法避免重復領取請求，並且RocketMQ也不保證不會重復消費消息，在業務層消息去重保證冥等性、盡快拒絕重復請求對於紅包系統來說顯得尤為重要。由於系統去重依賴存在柔性策略，不能完全依賴單一機制來實現完全去重，系統通過紅包接入代理層領券狀態機、限量服務、卡包記錄三種機制依次對請求進行校驗去重。
4.4 熔斷降級
在紅包發貨過程中存在多點依賴，並且這些依賴存在故障不確定性，需要考慮在這些故障點觸發的時候做到最大化的無損，系統在可柔性處理的三個模塊位置增加熔斷降級開關，在故障失敗出現時熔斷切換備用策略或者直接降級放棄依賴
-
領取狀態CMEM存儲熔斷開關
“紅包狀態存儲”雖對整個系統至關重要，但在出現故障時也不能影響用戶領紅包業務，通過在該模塊依賴鏈路上增加熔斷開關，當出現超時、不可用故障時，解除對該模塊的依賴，避免非關鍵路徑對整體活動的致命影響。 -
Rocket MQ 降級開關
MQ生產為本地agent代理方式，除了本地共享內存緩沖外，為避免RocketMQ長時間故障影響消息生產，支持手動熔斷消息生產，切到klog系統記錄紅包領取消息，並通過對賬補發腳本對用戶領取請求進行補發重做。 -
計平查券接口自動降級
用戶在拉起支付的時候會觸發拉取當前可用券信息，這個拉取動作默認會打到計平的查券接口，在容量評估期間，計平大部分資源都騰挪到抵扣券發貨上，對查券和支付只保證支持1.5k/s能力，為了增加對計平系統的保護，同時讓用戶能正常支付用券，物品系統增加對查券接口設定降級機制，如果在周期內故障達到事先設定的閾值時自動降級，將請求切換內部本地卡包服務，並通過核銷對賬來保證與計平的數據一致性。
4.5 快速失敗
- 公眾號消息服務快速失敗
用戶每成功領取一個紅包都需要收到公眾號消息，發送公眾號消息成為領紅包路徑的必要事件點，在公眾號消息系統部分機器故障時如果不快速失敗將會降低紅包整體發貨性能
4.6 緩存
-
緩存加速
- 對紅包抵扣券基礎信息本地cache加速，減少cmem訪問和發貨時延。
- 采用錢包側領取碼，節約動態生成領取碼的資源耗時
-
Rocket MQ緩沖屏蔽后端發貨故障 后端發貨系統內部依賴多，計平發貨能力有限，通過MQ一方面緩沖紅包領取消息，同時屏蔽了后端邏輯系統故障對整體春節紅包活動的影響，實現故障無感知
5. 活動緊急預案
雖有容災策略，依然無法保證萬無一失，我們需要梳理整個系統所有關鍵節點，並對關鍵節點設計故障演練修復方案
關鍵點1：后端物品發貨大面積失敗
后端物品發貨依賴復雜，從邏輯校驗到限量再到midas發貨，任何環節故障都可能觸發發貨故障 干預策略:在故障出現時第一時間降速（對切換了本地限速服務的消費機，需要暫時停止消費機），之后再排查具體的發貨故障
關鍵點2：RocketMQ生產失敗
RocketMQ為紅包單獨部署了紅包集群，雖無法生產的可能性比較低 干預策略:
- 采用本地agent生產機制，利用本地共享內存對MQ進行容災
- 若出現生產失敗情況使用klog對失敗消息記錄並統一進行對賬重做
關鍵點3：領券公眾號通知長時間無法修復
干預策略:
- 公眾號消息如果遇到故障短時間能恢復可以通過重試處理即可
- 若公眾號消息故障長時間無法恢復（超過10分鍾），可直接關掉公眾號通知機制，在通道恢復正常后恢復公眾號通知，保證故障期間禮包正常到賬，犧牲無消息通知的體驗。
6. 數據采集監控
系統在接入TNM2特性告警、米格告警、模調同時監控系統運行狀態
7. 分段壓測、全鏈路壓測
與錢包后台側壓測性能達到預估要求5w/s 米大師抵扣券發貨性能峰值通過幾輪壓測最終可達1.3w/s 查券接口可達3.5k/s
- 項目上線之后除了參與多輪紅包演練外還執行了分段壓測，之所以需要分段壓測是因為在服務上線之后，依賴的鏈路中存在部分系統完成擴容、部分系統未升級，所以前期很可能不具備全鏈路壓測的條件，如果貿然執行全鏈路壓測，很可能會導致部分依賴服務過載無法提供正常的業務服務；
- 在壓測過程中提前申請測試帳號，因為部分系統如果帳號空間有限的話可能無法反映真實流量情況，如果條件允許的話建議按照預估的QPS來申請，本次為配合壓測申請2w個測試賬號；
- 在所有系統擴容結束並完成分段壓測后，需要對全鏈路進行壓測；
- 對壓測相關服務保證與當前線上提供的服務環境隔離，避免因為壓測影響正常業務，
- 對有依賴CMEM服務，單獨申請臨時CMEM用於壓測，構建壓測環境;
8. 故障處理
介紹了這些准備工作和預案，那么在除夕大流量來臨時我們是否有遇到現網故障呢，怎么修復現場 ？
-
CMEM故障
第一時間聯系數據運維現場值班同事定位問題，之后對消費速度降低避免過多的消息進入“重試隊列”，同時降低對CMEM的沖擊在CMEM負載修復之后，逐步放量 -
消息隊列消息堆積
在除夕當天出現因CMEM告警導致了請求無法走正常發貨渠道到賬，從而堆積在消息隊列里面，為了保證在零點前全部禮包到賬，在數據運維同事處理的同時，業務側首先停止部分消費機並將速度降低到500/s，以控制較少的請求到達重試隊列。在CMEM故障恢復之后逐步放量，並擴大進程消費線程數來提高重試隊列的消費速度，最終在23:20將所有消息消費完畢
9.經驗總結
- 處理失敗消息執行再生產
在大流量依賴MQ消費消息過程中，如果遇到消息處理失敗，最好執行再生產，否則將會進入“重試隊列”，影響消費速度，從而會導致部分用戶物品無法在產品預定時間到賬。 - 確認依賴的CMEM是否已經關閉數據下沉
部分大容量CMEM很可能在過往開啟了tssd關聯，在大流量進來很可能會導致tssd過載，影響cmem整體可用性。 - 不斷完善紅包項目checklist
從紅包項目需求啟動時，創建並不斷完善check項，方便除夕活動開始前依次檢查。 - 普通活動與春節紅包服務獨立部署或者錯峰推廣
在春節期間，除了春節紅包項目外，可能有其他活動推廣，如果無法對普通活動做到錯峰推廣，需要為春節紅包項目獨立隔離部署服務，避免相關資源競爭影響。 - 壓測環境與正常業務環境隔離
由於在壓測過程中很可能出現故障，同時我們紅包項目的大部分服務都是在現有業務服務的基礎上實現，所以我們需要保證壓測的系統與當前業務服務環境隔離。 - MQ消費隊列數與消費進程配置合理，保證最好的消費並行度
在配置消費隊列數和進程數與MQ集群節點數匹配，保證最好的多機並行消費狀態，單機消費進程數在機器條件允許的情況下不要配置過高，盡量讓隊列負載到不同的機器上去。 - 確定值班聯系人
在活動開始前確認各個依賴模塊的值班聯系人，方便在模塊出行問題時第一時間知會相關同事，節約溝通成本，縮短故障持續時間 - 提前保存相關服務配置信息
在checklist里加上需要重點關注的配置信息，如CMEM bid地址、服務L5、開關配置，在需要定位時快速執行，減少查找信息的時間
問答
針對移動web的PayPal自適應支付如何實現？
相關閱讀
10億紅包背后的數據中心
淺談數據中心應急冷源
如何搭建一個紅包架構?
**此文已由作者授權騰訊雲+社區發布，原文鏈接：https://cloud.tencent.com/developer/article/1145740?fromSource=waitui **
歡迎大家前往騰訊雲+社區或關注雲加社區微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐干貨哦~