?作者 ｜ 齊建朝
背景
近幾年春節期間，抖音都會為用戶帶來各式各樣的春節活動，每年都會有數億用戶參與其中。2022 年春節，抖音支付也參與了春節活動，面向海量用戶發放抖音支付券，幫助用戶在抖音春節活動中獲得更好體驗。對抖音支付來說，這是一個很大的挑戰，因為之前抖音支付團隊沒有真正意義上經歷過春節活動這種量級的應用場景，這對抖音支付營銷系統是極大的考驗。
抖音支付營銷系統簡介
當前營銷系統分層及架構如下：
營銷團隊業務主要分為三大方向，營銷投放、營銷活動、營銷資產。營銷投放主要負責營銷權益觸達，將營銷利益點曝光給用戶，營銷活動主要負責營銷玩法的建設以及權益發放，營銷資產則主要負責用戶營銷資產的管理，比如優惠券、立減的發放及使用等。對于春節發券，鏈路是由營銷活動對接春節主會場玩法，調用營銷資產接口將支付券發放到用戶手中。
挑戰
- 春節活動并發量大，同時參與領券的人數會非常多，高峰期對系統造成的沖擊會非常大。
- 春節活動面向全國用戶，受眾非常廣，用戶體驗非常重要，因此發券動作耗時需要盡可能的低。
- 春節活動參與人數基數非常大，春節期間預計發放的支付券數量也會非常多，資金安全需要重點保障。
方案
性能保障
異步發券-提升接口響應速度
考慮到支付券使用大多在抖音電商場景，且春節期間用戶線上購物流量較小，用戶領到券后立即使用的概率較低，只需要保證用戶領券到實際感知券(查看券或使用券) 的時間延遲可控，那么用戶體驗就不會受到影響，因此我們采用了異步發券的模式，營銷收到上游發券請求后，落單后立即返回，通知上游受理成功。
異步發券帶來的一個問題是用戶領券后感知到領券成功，實際券最終沒有發給用戶，大部分為庫存不足、風控攔截等原因。針對這個問題，我們與運營同學做了討論，春節期間營銷活動庫存會盡量配置的足夠多，風控攔截率會降到最低，除異常刷單用戶外均不做攔截，盡量降低異步發券失敗的可能性。
雙層本地隊列-提升處理能力，平滑流量
將流量異步化后，因為活動流量大都是心電圖的結構，波峰波谷很明顯，我們借鑒了生產者-消費者模型，引入了隊列來平滑流量。一開始我們考慮了 RocketMQ，但一旦在活動發券核心鏈路上引入了額外的中間件，便對其產生了依賴，需要額外考慮它的可用性和容災方案，且 RocketMq 屬于遠程隊列，生產者消費者之間的延遲也不易控制，因此我們設計了一套本地隊列模型，來規避上述問題。
本地隊列模型如上，隊列消費端邏輯首先會從分布式限流器獲取令牌，獲取成功后再從隊列中獲取數據，新建一個 goroutine 處理活動發獎邏輯，之后重復此流程。
雖然隊列本身有削峰的作用，但還是不能精確控制消費速率，當上游流量過大時，隊列消費端消費速率也會隨之上升，有打崩系統的風險，所以還是需要限流層做較為精準的流量控制，但僅靠接口維度的限流粒度又太粗，所以在業務邏輯層又引入了一層業務限流。這里的分布式限流器使用的支付自研的分布式限流組件，優先會從本地獲取令牌，當本地令牌不足時，會從遠程批量拉取令牌到本地。
另外這個模型我們使用了雙層隊列，第一層隊列用于保護營銷活動層，基于營銷活動處理能力設置限流；活動決策通過后，再將請求放入第二層隊列，第二層隊列的限流則是基于營銷資產的系統承載能力來設置。通過雙層隊列，可以規避掉營銷活動和營銷資產間的容量差異，兩方系統吞吐量都可以最大程度地發揮出來。
庫存扣減優化-減熱點，降壓力
出于性能的考慮，營銷資產的券批次庫存放在了 Redis，目前營銷資產庫存操作的邏輯是：收到一個用戶的發券請求->讀取 Redis，查看發放的券批次庫存是否充足->寫入 Redis，扣減券批次庫存。
為了使 Redis 集群流量均勻，不同券批次的庫存數據被打散到了不同的 Redis 分片上，但是當在一段時間內集中發放某一券批次時，流量仍然會大量偏移到一個分片內，造成 Redis 數據熱點問題。如果想辦法能將某個券批次多次零散扣減庫存的操作合并到一起，那么數據熱點問題就可以會得到較大的緩解。
合并發券邏輯如上圖所示，營銷活動嘗試首先從二層隊列中非阻塞地獲取 N 條發券請求數據，如果可以拿到，則將這些數據打包發送到營銷資產，如果從隊列中拿到的數據小于 N 條，說明此刻隊列沒有更多的數據，直接將券盡快發出；如果獲取不到數據，則隨機睡眠一小段時間之后，重新嘗試獲取，如果經過有限次重試后仍獲取不到數據，則結束此次循環。
營銷資產收到合并發券的請求后，會嘗試對請求中相同券批次的發券請求進行合并，扣減庫存時進行集中扣減，比如之前為 N 個不同用戶發放同一券批次 A，每次庫存減 1，需要對 Redis 進行 N 次寫操作；合并發券后，只需對 Redis 進行 1 次寫操作，庫存扣減 N 即可。
另外，扣減庫存前的校驗邏輯，實際上不需要每次都去訪問 Redis，這次校驗本身只是一個前置校驗，最終扣減是否成功還是取決于之后扣減操作的執行結果，校驗的最大作用是在 Redis 庫存不足后能將不必要的扣減動作攔截掉，并不需要十分精準，因此我們考慮在應用本地內存維護了一份券批次的庫存信息，定時將 Redis 庫存信息同步到本地，發券時只需要在本地內存簡單校驗庫存信息即可，不需要再訪問遠程的 Redis。
優雅退出-完善系統魯棒性
使用本地隊列進行數據處理的一大弊端是內存易失性會使數據無法持久性地存儲，在應用重新發布或升級時，本地隊列中的發券數據有可能會丟失，用戶發券請求無法得到正常處理。
為了內存中的數據不丟失，我們需要能夠感知到應用退出的信號，在應用退出前將內存中的數據處理掉。因此我們調研了字節云應用實例的生命周期，在實例終止時，首先會將當前應用實例從服務注冊中心中摘除，此操作執行后意味著當前實例不再接收新的外部流量；之后會發送 SIGINT 退出信號給業務進程。應用收到 SIGINT 信號后，不再消費隊列中剩余的發券請求數據，而是將這些數據發送到遠程隊列中，由當前仍存活的其他應用實例來消費這些數據。
兜底補償-保證最終一致性
盡管已經實現了應用優雅退出，但是在極端情況下，比如 panic、oom、物理機宕機等異常情況引起的應用退出，應用是接收不到 SIGINT 信號的，也就無法執行優雅退出的業務邏輯。因此我們額外增加了兜底補償機制，通過定時任務掃表，將卡在中間狀態時間較久的數據重新投遞到本地隊列中進行處理。
既然有了定時任務做兜底補償，那么優雅退出邏輯是否還有存在的必要呢？其實還是有必要的，當應用上線過程中會發生頻繁的應用重啟，此時很可能存在大量本地隊列的請求未得到處理，如果僅依賴定時任務兜底處理，那么用戶從領券到實際收到券的時延可能會非常大，有可能會造成用戶體驗變差。因此優雅退出和兜底補償是一個互補的關系，優雅退出最大程度保證用戶體驗，兜底補償保證數據的最終一致性。
綠色通道-提升用戶體驗
異步發券的假設是用戶從領券動作發生，到實際感知到券的存在，中間是有一段時間緩沖的，但是用戶有可能領到券后直接進入春節錢包查看，如果此時異步發券還未完成，有可能會造成客訴。針對這種情況，我們與上游春節主端做了約定，當用戶領券后短時間內進入春節錢包查看優惠券時，上游會再次調用發券接口，并增加綠色通道的標識，我們收到這個標識后會將異步發券變更為同步，優先為當前用戶發券，保證用戶體驗。
資金防控
除了性能方面的保障，資金安全也需要重點關注，在本次春節發券活動中，我們主要做了以下防控措施。
冪等校驗
每一次發券動作都會生成一個全局唯一的序列號，發券時會將序列號作為唯一索引落入數據庫中，當發生用戶連續點擊領券或網絡異常重試等情況時，相同序列號由于唯一索引沖突落庫無法成功，從而避免重復發券帶來的資金損失。
用戶維度領取限制
通過序列號進行冪等校驗可以解決一部分問題，但對于一些較為專業的黃牛黨來說，可能會繞過這個限制，通過偽造序列號的方式繞過冪等校驗。對于這種情況，我們維護了一份用戶券批次的領取數據，發券會校驗每個用戶是否達到了領取上限，未達到領取上限則會正常發券，同時對用戶領取記錄進行更新，否則終止發券動作。
券批次組互斥
用戶維度領取限制主要防止同一用戶多次領取同一批次的可能性，但是在整個春節活動中，運營同學可能會發放多個用途不同的券批次，但是發放的群體有可能會重疊甚至是同一批，如果對用戶多次發放不同批次的券，有可能會拉高營銷成本?；谝陨显?，我們抽取出了券批次組的概念，處于同一組的券批次，營銷目的基本是一致的，比如都是拉新、促活或留存的目的，當用戶領取了券批次組內的一種券后，用戶便不可以再領取組內的其他券批次，即組內的券批次間為一種互斥關系，通過這種方式避免造成營銷費用重復補貼。
庫存防超賣
上文提到過，營銷券批次的庫存數據存放在了 Redis，每次對 Redis 進行庫存扣減時，可能會存在網絡超時、失敗等異常情況，造成扣減庫存的結果處于未知狀態。當這種情況出現時，我們選擇"容忍"，認為發券失敗，直接結束發券邏輯，不做回滾處理；扣減庫存成功后，再為用戶實際發券，如果發券失敗，此時可以嘗試回滾 Redis 庫存，因為已經確定本次請求成功扣減了庫存，但是回滾失敗，不再做額外的重試處理。
上述方案，有可能造成庫存少賣，但這種較保守的策略可以有效防止庫存超賣的可能性，可以看做在數據一致性和可用性之間的一種取舍與平衡。
風控平臺接入
在發券鏈路中，我們也接入了字節內部的風控平臺，風控平臺會采集分析用戶及設備等信息，通過風險評估將黃牛及惡意用戶識別出來，攔截發券動作，避免潛在的資損產生。
數據監控與核對
除了以上的資金防控措施外，我們還對發券活動做了大量監控，包括券批次發券量，券批次發券速率、本地隊列堆積情況、本地隊列消費者速率等等，當監控數據出現同比或環比異常時會及時報警并人工介入排查。另外，當券批次發放完畢后，我們會再次核對數據的一致性，包括比對用戶發放券張數與庫存消耗數量是否一致、校驗單用戶是否超過券批次領取上限等等。
總結
經過以上方案的優化，我們順利的支撐了今年的春節主會場發券活動，并取得了不錯的效果：
系統上
- 營銷整體對外可承接十萬級 TPS 的發券吞吐量。
業務上
- 春節期間發放了數千萬張抖音支付、DOU 分期券，支持了抖音支付、DOU 分期兩大核心業務的活動訴求。
- 99%的券可以在 0.5s 內發放到用戶賬戶中，異步發券實際延遲很低，用戶體驗較好，符合業務預期。
后續規劃
經過今年春節活動流量的考驗后，營銷沉淀下了不少經驗和系統能力，不過仍有需要后續持續迭代和完善的地方：
- 異步發券能力標準化。我們初步嘗試了異步發券并應用在春節活動中，取得的效果不錯，可以預見之后的 618、雙十一等大促節日仍會有很多適合異步發券的場景，因此我們準備將營銷對外的發券接口標準化，將異步發券作為一種可選能力，與接入方、場景等關聯起來，做到發券模式的靈活選擇與配置。
- 本地隊列模式推廣。本次設計并實現的雙層本地隊列，很好地完成了發券任務處理，任務執行相比遠程隊列時延更低，隊列分層、限流、優雅退出、補償等輔助功能對系統魯棒性也有較好的保障，后續我們會將此模塊抽象成一個通用的小框架，使其可以支持更多適合異步處理的業務場景。
