導語：騰訊計費是孵化于支撐騰訊內部業務千億級營收的互聯網計費平臺，在如此龐大的業務體量下，騰訊計費要支撐業務的快速增長，同時還要保證每筆交易不錯賬。采用最終一致性或離線補償的方案往往會帶來較多的處理風險或投訴。因此，我們提出了一種通用的基于應用層的長事務解決方案，將復雜的分布式一致性問題化繁為簡。

1 引言

英國計算機專家Hoare所言，軟件設計構建有兩種方法，一是使其盡可能簡單，從而一目了然確定其中不存在缺陷；另一種方法則是使其極為復雜，以至于看不出什么明顯的缺陷。然而，實現第一種方法要困難的多。

騰訊計費是孵化于支撐騰訊內部業務千億級營收的互聯網計費平臺，目前匯集國內外主流支付渠道，提供賬戶管理、精準營銷、安全風控、稽核分賬、計費分析等多維度服務。平臺承載了公司每天數億收入大盤，為上百個國家（地區）、萬級業務代碼、 百萬級結算商戶提供服務，托管賬戶總量 300 多億，是一個全方位的一站式計費平臺。

在如此龐大的業務體量下，騰訊計費要支撐業務的快速增長，同時還要保證每筆交易不錯賬。然而在分布式場景下要滿足ACID，保證所有操作均執行成功才提交結果，隨著分布式規模的擴大要達成一致性的時間周期越長。例如，Bitcoin的Scalability問題，為了滿足一致性一筆交易的平均確認時間需要10分鐘。因此，為了適應復雜的業務場景出現了Base理論，使用最終一致性來代替強一致性。在計費場景下，通常的一些最佳實踐是：

• 先長款后短款原則。由平臺方掌握主動權，即使出現異常情況下也可以通過補償的方式保證一致性。例如，先支付后發貨，若發貨失敗通過重試機制達到最終一致。

• 臨界資源訪問盡量使用樂觀鎖。例如，在讀多寫少場景使用樂觀鎖實現互斥，在保證一致性的前提下提高并發處理能力。

• 遠程服務調用保證可重入。例如，已經支付成功的訂單，如果再次提交也不允許重復支付。

• 非關鍵服務異步化。例如，對于支付旁路的操作，通常借助消息中間件進行解耦處理，并保證最終執行完成。

• 服務全鏈路實時監控。關鍵操作實時上報，監控每一步的成功率和轉化率，做到異常的實時發現。

通過上述等機制，在異常情況下可做到讀修復，寫修復，異步修復等，以保證事前和事中的交易高一致。但考慮到問題的閉環，我們也建立了一套完善的針對實時訂單，異步訂單，離線訂單的三級對賬機制，以做到事后的保證。

然而，對于日均過億的交易量，采用最終一致性或補償性的方案往往會帶來較多的處理風險及投訴，需要我們做到實時的一致性。同時，計費系統的邏輯多且復雜，目前涵蓋了近百個特點迥異的支付渠道，異常處理強依賴開發者的經驗，需要由平臺統一處理異常問題來提高服務的容錯性。隨著業務系統的發展，系統會有不斷的新功能迭代，加強邏輯的可管理性從而降低開發門檻，也是我們需要考慮的。

化繁為簡是我們的目標，為了應對上述挑戰，結合我們在計費領域的多年工程實踐經驗，決定著力打造一套通用的基于應用層的分布式高一致解決方案TDXA (Titan Distribute eXtended Architecture)，將復雜的分布式一致性問題交給引擎平臺處理使業務開發更加聚焦，主要實現以下目標。

• 分布式事務的原子性，保證交易實時高一致。

• 自動的異常處理，提高容錯性。

• 基于狀態機的流程管理，加強流程的可管理性。

TDXA通過在內部業務的試點，基于TDXA實現的計費服務，上線后通過對賬統計發現異常的交易訂單數量明顯減少，整體服務質量提高。同時，由于TDXA屏蔽了復雜的異常處理，業務開發效率也隨之提高，相同需求的開發工作周期較之前減少了近50%。

2 設計思路

2.1 分布式事務

在工程上，作為完整的計費服務，一致性不僅需要考慮數據層的數據一致性，同時也要考慮應用層的邏輯一致性。比如，轉賬這個行為，數據層可以保證每次數據的更新一致性，而應用層如果只減不加，用戶看到的賬戶數據也是不一致的。交易的一致性，簡單講就是收對錢，發對貨。看似簡單的描述，但在實現中卻面臨了很多約束，導致容易出現一致性問題。比如：

• 計費功能模塊多，業務邏輯復雜

• 支付交易鏈路長，一筆流程多達幾十次rpc

• 業務請求峰值高，分布式服務節點多

• 請求響應時間低，需要保證用戶體驗

• 系統部署環境差，網絡超時錯誤多

在OLTP場景下，用戶的一次購買請求通常會涉及多個后端服務的操作，如果其中某一個服務調用出現了二義性錯誤（網絡超時），此時應該返回失敗還是成功，之前調用過的服務是否需要回滾？倘若請求量小的情況下，可以借助人工來處理部分調用異常，但是當請求量大了以后，人工介入的成本就非常高。

計費服務的整體質量要求至少達到四個9，同時不允許交易出現壞賬，對外提供事務一致性保障。從一致性的本質來看，要么保證在一個業務邏輯中包含的服務都成功，要么都失敗。在計費場景下，后端服務可能涉及接口，數據庫，分布式緩存，消息隊列等，我們希望做到針對不同后端資源的長事務一致性。

我們的做法是，通過引入分布式事務管理器（Transaction Manager），將全局事務分解為多個子事務，并交給不同的資源管理器（Resource Manager）處理。同時，針對不同的資源類型抽象為不同的事務處理模型，幫助業務實現自動的事務提交或回滾。面對復雜的長事務流程，業務可以自定義組合不同的事務模型，并根據業務自身特點指定不同的異常處理策略（Error Strategies），讓業務開發像處理單機事務一樣來保證整體分布式事務的一致性。通過這樣的方法，可以有效地幫助業務開發減少異常處理，更專心地實現業務核心邏輯。下面分別對不同的事務模型說明如下。

• TCC事務模型
  分別代表Try，Confirm，Cancel。此事務模型類似兩階段提交協議(2PC)，用于保證分布式事務的一致性。與2PC不同的是，對資源的加鎖是業務資源級別的隔離，減小了資源鎖的粒度，因此在事務沒有完成提交或回滾時，可以允許執行其他事務。TM根據所有RM的反饋來決定提交或中止事務，如果所有的RM全部執行成功則提交，但只要有一個失敗則回滾事務。此模式需要后端服務提供相應的資源操作接口，并保證冪等。調用關系如圖2.1所示。

• DB事務模型
  DB事務模型相比TCC事務模型，主要針對原生的數據庫操作，減少了對業務的侵入性，由引擎根據用戶提交的SQL實現跨數據庫實例的操作。因為基于傳統的關系型數據庫本地事務特性，DB事務模型不允許跨連接，而TCC事務模型沒有這個限制。針對這個問題，對于包含異步處理的事務流程，一種做法是，引擎會先把已經執行的SQL進行COMMIT，并根據后續接收到的異步通知結果來決定繼續正常執行，還是執行SQL反事務。另外可以結合數據庫的外部XA特性，通過兩階段提交的方式，對于Prepare成功的操作實現數據庫事務的跨連接，根據異步執行的結果來決定是Commit還是Rollback。調用關系如圖2.2所示。

• TRY_BEST事務模型
  此事務模型表示盡最大努力執行，主要用在邏輯上可以保證一定執行成功的RPC調用。例如，用于一些通知類接口。在整個事務執行流中，建議放在最后執行，以保證整個事務的執行成功。調用關系如圖2.3所示。

除了以上常見的幾種事務處理模型，我們也在不斷完善新的事務模型。其中每種事務模型都定義了相應的回調接口由業務實現（如下表所示），同時在使用上也有一些約束準則要求。

TRY_BEST和TCC兩種模式調用的RPC接口需要保證冪等。

三種模式支持混合使用，但是需要保證調用順序，最佳實踐是優先執行可以回滾的操作。例如，TRY_BEST和TCC兩種模式混合使用，應該先執行TCC的子事務，然后再執行TRY_BEST子事務，這樣如果執行TCC子事務失敗可以回滾，如果TRY_BEST子事務執行失敗可以通過補償最終保證成功。

最后，以用戶轉賬為例看如何實現混合類型的事務流程。首先在第一階段，調用訂單服務創建一筆訂單（try），然后提交轉賬sql1和sql2。第一階段執行成功后并對用戶發起一條消息通知（do）。若第一階段執行成功，在第二階段，框架會自動完成第一階段的確認過程（confirm和commit）；若第一階段出現異常，框架也會自動完成回滾過程（cancel和rollback）。業務開發需要保證業務邏輯上的合理性，將可以回滾的操作先執行，而由框架保證整體事務的一致性。

具體交互過程如下圖所示。

2.2 自動的異常處理

根據墨菲定律，事情如果有變壞的可能，不管這種可能性有多小，它總會發生。我們的系統服務也是，雖然大多數情況都是可以正常對外提供服務的，但是在少數情況下也會出現服務不可用，網絡超時等問題。因此，當服務調用出現異常時，如何保證事務可以繼續自動執行完成？一種可行的方案是，將事務狀態保存和業務事務通過數據庫本地事務打包成一個原子事務，當異常出現時，可以通過一個消息重放服務將事務繼續執行完成。

此方案的特點是，存在一定的業務侵入性，并且依賴單機DB的處理性能。為了解決這樣限制，提出了另一種基于消息中間件的方案，首先消息中間件本身需要保證數據的可靠性，同時，在客戶端通過引入一個生產代理Proxy，來解決在無法及時寫入的情況下，使用本地存儲充當一個緩沖區。通過結合本地隊列和遠程分布式隊列構成一個可用性更高，延遲更低的分布式消息隊列方案。

|

因此，我們需要消息中間件滿足以下要求：

• 一致性：計費場景要求數據一條不能丟，這是最基本的訴求。

• 高可用：需具容災能力，在異常情況下能夠自動修復。

• 海量存儲：在移動互聯網時代，產生大量的交易數據，需要具備海量堆積能力。

• 快速響應：在億級支付場景下，要求能提供平滑的響應時間，盡可能控制在10ms內。

下面是我們基于Pulsar實現的一套高可靠的消息中間件解決方案，整體架構如下圖所示。

|

關于消息中間件的實踐經驗，我們團隊在Apache Pulsar Meetup北京站也做過一次分享，可以參考另外這篇文章Apache Pulsar 在騰訊計費場景下的應用。

2.3 狀態機的流程管理

由于計費流程的復雜性，通常一筆完整的支付請求需要至少幾十次的rpc調用。我們希望加強對流程的約束管理以減少可能的邏輯錯誤。我們的主要解決思路是，通過狀態圖定義服務調用流程，基于事件進行驅動來完成整個流程。其中，每個節點表示一個rpc操作，每個rpc操作分為三個獨立過程（Pre/RPC/Post）；每條邊上可以定義多個算子，通過算子的返回值實現服務路由。

|

同時，通過引入有限狀態機白名單的方式，保證業務狀態的流轉是合理的，可規避一些不必要的業務邏輯錯誤，減少異常錯誤的發生。例如，不會出現已經支付的訂單被再次提交支付，即Double Pay的問題。

業務開發只需要關心業務節點注冊的Pre和Post回調接口的具體實現，以及每個業務節點操作結果的返回算子，其余工作由框架完成整個流程的驅動，以及分布式事務的提交或回滾。同時，我們支持將當前的事務狀態通過Json描述出來，并轉換成流程圖，讓復雜的流程更加直觀。

3 系統架構

騰訊計費高一致TDXA，旨在幫助業務解決長事務的一致性問題，通過使用狀態機來控制事務的執行路由，基于插件化注冊機制，提供多種子事務處理模型，實現對不同類型資源的分布式事務處理，完成自動化的提交或回滾。并提供規范的二進制對接協議，以及Java等語言二次開發能力。整體架構如下圖所示。

對每個模塊的功能簡要說明如下：

• TM: 主要實現流程的注冊，分布式事務控制，以及異常策略處理。

• CM: TM的配置管理，包括流程注冊配置信息，節點的屬性信息，事務類型。

• Producer: MQ的生產代理，事務的持久化，及異常情況的事務重試。

• Consumer: MQ的消費代理，執行業務指定的事務補償策略。

• RM: 實現外部接口協議轉換，及提供具體的業務資源接口，由TM調用。

• TDMQ: 保證消息完整性和低延遲的分布式消息隊列。

TDXA的內部工作流程，主要分為三個部分：

• 初始化流程

a) ? ?初始化時，TDXA將從配置服務獲取要加載的所有注冊so或xml流程配置，并依次加載。
b) ? ?加載后通過回調協議接口取得要注冊的流程名及對應的注冊函數。
c) ? ?通過調用注冊函數完成流程注冊。

• 正常執行流程

a) ? ?通過解析業務請求中的事務流程名，創建需要執行的流程，并將請求數據添加到事務的數據池中。
b) ? ?初始化事務狀態為begin，并通過轉移條件決定下一個要執行的狀態。
c) ? ?執行當前狀態的預處理和對應服務的執行調用。
d) ? ?根據執行結果判斷服務路由，若沒有找到滿足的路由，則根據業務指定的錯誤策略完成事務恢復。
e) ? ?重復執行c~d，直至達到狀態end，或發生異常情況。
f) ? ?最后根據事務的執行結果，設定事務返回信息。

• 事務恢復流程

a) 反序列化分布式消息隊列通知的事務信息。
b) 對未完成的事務斷點執行。

為了方便業務快速接入，我們實現了一套前端自助化流程配置和功能驗證系統。希望能夠幫助業務在接入時做到盡量能所見即所得。前端每生成一個節點， 就會生成一份對應的后臺代碼， 支持分Tab頁代碼編解功能。為方便重度開發人員，頁面上也可以下載整體的含框架代碼，開發者可以選擇使用其他的IDE進行開發。

4 系統可靠性

4.1 邏輯可靠性

TDXA內部提供了一些必要的邏輯異常檢測機制，幫助業務規避不必要的錯誤，包括但不限于：1，注冊接口參數檢測。2，DAG（Directed Acyclic Graph）合理性檢測，需要滿足，僅有一個連通分量，不能回環（但允許自環），每個節點都能達到終止節點保證閉環。3，運行時異常流程錯誤告警等。

TDXA對于業務異常的流程處理原則分為兩類。對于業務類錯誤，引擎會把控制權交給開發者，由開發者根據返回值信息決定事務流程如何流轉；對于系統類錯誤，引擎會返回E_PROCESSING錯誤碼給前端，然后內部借助消息中間件進行異步重試處理，其中重試次數和時間間隔均可由業務決定。

4.2 服務可靠性

在服務可靠性方面，TDXA中的事務管理器TM是與業務服務集成在一起的，并通過消息中間件實現事務的持久化。考慮可能出現的以下幾種組件異常情況，以及如何實現故障遷移。

情況一：在TM進行事務持久化前，TM出現故障。此時，可以通過原始的事務請求進行重放。

情況二：在TM完成事務持久化后，TM出現故障。此時，未完成的事務可以由集群中其他的TM繼續完成處理。

情況三：在TM進行事務持久化時，TDMQ出現故障。此時，通過本地的TDMQ Proxy異步重試。

情況四：在TM進行事務恢復時，TDMQ出現故障。此時，會選取新的可用的Broker進行消費，可能出現多次消費，需要業務保證冪等處理。

5 系統性能優化

事務的核心是鎖，而事務和性能是兩個相悖的特性，因此在滿足分布式事務的前提下，也需要考慮對系統性能的調優，通常的優化方法包括：1，盡可能減少鎖的覆蓋范圍。2，MVCC多版本并發控制協議，讀寫不沖突。3，選擇正確的鎖類型。悲觀鎖適合并發爭搶比較嚴重的場景，而樂觀鎖適合并發爭搶不太嚴重的場景。TDXA在性能調優方面做了以下考慮。

優化1：通常引入事務協調者會增加網絡調用次數，因此會減少系統的并發處理能力。為了盡量減少不必要的網絡調用，我們將事務協調者與業務服務集成在一起實現，提供了插件和配置的方式注冊業務事務。

優化2：允許不相關的事務可以并行執行，即pipeline操作。例如，b0~b3與c0~c3是兩個獨立的操作流程允許并行執行。

優化3：對于TCC事務模型，操作相同資源的不同事務是獨立的，不需要等待執行。例如，事務T1在沒有confirm或cancel時，事務T2可以繼續執行try而不需要等待事務T1完成。

優化4：針對數據庫外部XA的性能優化。在XA模型下，如果由于不穩定的網絡通信導致事務沒有提交，會影響所有其他事務都在等待。我們針對數據庫的網絡模型增加了線程池的處理模式提高了I/O的處理能力，較原生的半同步方式提高了近5倍的性能。具體可以參考計費平臺部高一致性存儲層架構變遷之路---分布式MySQL數據庫(TDSQL)架構分析

6 下一步方向

騰訊計費作為承載每年千億級業務營收的計費平臺，保證支付交易高一致，每筆收支不錯賬是我們的核心能力。分布式服務相比單體服務，為我們提供了更好的擴展性和靈活性，但也帶來了復雜的一致性問題。騰訊計費高一致TDXA在此背景下應運而生，旨在實現長事務的一致性，支持多種資源的混合分布式事務，在異常出現時可以實現零人工介入處理。讓復雜的問題在這里變得簡單，化繁為簡是我們的目標。最后，考慮到極端情況，我們還會借助三級對賬，通過實時訂單，異步訂單，離線訂單的三級策略，來保障異常情況下的交易一致性。

騰訊計費通過多年的實踐探索，我們構建了一套完整的金融級計費解決方案，TDXA作為其中的一個重要組成部分，其他的還包括TDSQL，TSM，TBC等。目前，TDXA已經在騰訊計費內部業務廣泛應用，包括，大額的企業支付，騰訊云計費，騰訊計費開放版等，在實際場景中得到了驗證，減少了不必要的人力成本，業務服務質量得到顯著提高。

最后，我們在解決了一些問題的同時，也遇到一些新的問題。

兼顧易用性和性能。目前，TCC的模式，將一次操作分成兩個獨立的子事務，不會阻塞其他的事務執行，可以保證較高的并發處理能力。但是依賴業務的接口實現資源的互斥隔離，對業務的實現存在一定侵入性；而DB的模式，目前是通過數據庫的外部XA事務實現的，可以支持原生SQL的分布式事務，減少了對業務的侵入性，但是由于資源是通過數據庫行鎖進行隔離的，只有提交或回滾的事務釋放資源后才能繼續處理其他的事務。易用性和性能的平衡是我們繼續優化方向。

支持更多的開發者。考慮到執行效率，TDXA的核心是通過C++實現的，并提供了C的接口給業務使用。考慮到可以推廣到更多的開發者，我們基于C的接口使用JNI封裝了Java的接口，從而也可以支持Java技術棧的開發。除此之外，越來越多新的高級開發語言出現，比如GoLang。如何將我們的能力普適給更多的開發者，也是我們后續需要考慮的。

事務隔離性要求。TDXA保證了長事務的一致性，但是卻犧牲了一定的隔離性。兩個事務并行執行的時候，其中一個事務可能讀取了另一個未提交事務的數據，即臟讀。對于大多數業務場景可能問題不大，可以通過事務補償來保證一致性，但是在某些業務場景下可能是不允許的。

支持更多的資源類型事務。TDXA的目標是希望業務可以像處理單機事務一樣處理分布式事務，目前已經支持RPC，DB等常見的接口。不難發現，對資源的加鎖都是后端接口提供的能力，為了支持更多的資源類型，在不依賴后端的前提下我們應該如何支持。

總結

以上是生活随笔為你收集整理的化繁为简 - 腾讯计费高一致TDXA的实践之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。