說到賬務系統，先介紹一下 58 到家的三大業務線：速運、家政以及平臺業務線。每條業務線都有各自的用戶、商家、以及運營補貼策略。

在開始階段我們並沒有統一的賬務系統，每個業務線都有類似賬務系統相應的系統。導致的問題就是資金池業務吻合嚴重，對賬難，以及數據不統一，另外成本也非常高，為此我們做了統一的賬戶系統。賬務系統作為到家業務線的基礎服務，為到家業務提供統一清算、賬戶、對賬、財務報表能力。

賬務系統概況

目前 58 到家賬戶系統的日均流水金額達千萬級別。我們按照業務線進行分庫,保證每個業務線落在同一數據源上，對於數量快速增長的表水平拆分。另外還對一些數據量增長較快，但是隻訪問近期新增數據的表做了冷熱數據分離，定期備份。

賬務系統架構

一. 支付平臺架構

以整個支付的流程來對支付平臺的架構做個說明：用戶下單 -> 交易生成賬單 -> 用戶確認支付 -> 交易校驗賬單 -> 生成交易請求 -> 收銀臺調起三方完成支付 -> 同步交易、同步業務線。此時交易系統會對卡券進行核銷。

交易系統完成後，賬單會推送到賬務系統，賬務系統進行記錄，清算，入賬等。

二. 清結算流程

因為 58 到家業務的特色，清算分為不同的模塊，有三方渠道、到家抽傭、罰款、獎金、到家補貼，優惠券，保險等。清算後生成賬戶流水，對賬戶流水做歸檔、覈算等處理。

三. 對賬系統

對賬系統是一個非常核心的系統。目前分為多級別對賬和多頻次對賬。多級別分為分賬對賬：對各種流水，以及總賬對賬，總分對賬：流水與總金額的對賬。多頻次對賬分為日對賬，準實時對賬，交易推送賬單之後約十分鐘進行檢查，賬務系統會查詢這筆賬單是否存在，以及對賬單的金額進行對賬。對賬系統會儘快的發現問題，進行差錯處理。出錯處理主要是掛賬、補單、退款和登賬。

四. 監控系統

賬務系統最核心的問題是穩定，保證數據準確，無異常，且能在第一時間發現問題，盡量降低問題帶來的影響。因此監控系統顯得尤為重要。

目前監管系統主要用來做異常報警和數據埋點。異常報警很好理解，就是系統中如果出現錯誤就會在開發時打錯誤日誌，掃描到有錯誤出現就會通過手機簡訊發送給開發人員，開發人員就會儘快查詢報警原因和對日常報警是否有數據影響，進行相應的處理。

數據埋點，就是對關心的數據做埋點(如每天獎金總額、罰款總額、賬單總額、商家提現總額)，對埋點數據進行收集、分析、展現。若展現的數據跟平常有較大差異，我們會找出數據差異原因，看是否有問題。保證有問題能及時發現，及時補救處理。

賬務系統的挑戰

從技術層面來說，主要分冪等性、數據一致性兩塊。

一. 冪等性

大多數系統會拆分成多個子系統服務,而一個子系統往往會調用另一個服務,服務之間相互調用就有可能出現伺服器處理完畢後沒有返回結果的情況。客戶端沒有接收到返回結果,就可能重複調用。冪等性是系統的介面對外的一種承諾(而不是實現), 承諾只要調用介面成功, 外部多次調用對系統的影響是一致的。

目前賬戶系統主要是根據業務需求做了幾種冪等性：

1. 充值時對充值流水號做了唯一的處理，外部調用充值介面時，傳一個唯一的流水號，判斷這個流水號在系統中存在，就返回，多次調用，也不會給這個賬戶進行累加充值。

2. 對獎懲做了外部唯一 ID 的冪等性，調用者會傳入唯一 id ,根據唯一 id 判斷此筆獎懲是否已經進行清分入賬。

3. 訂單則有區別，因為訂單有一個退款的流程，如果把訂單做唯一性，訂單發生退款時無法區分這個訂單是新增加的，還是退款的，這樣的話賬戶的金額就可能不準確。因此採用了賬單金額軋差。

訂單軋差是什麼呢？舉個例子，商家第一次支付的金額，傳到賬務系統進行清算，比如通過支付寶支付 100 元，那麼給這個商家進行入賬，入 100 元，下次該訂單發生了退款，假設退 90 元(此時交易系統會將該訂單實際支付金額傳到賬務系統，即 10 元)，實際上本次需要給商家入賬 -90 元，而不是 10 元，此次用賬單的金額 10 元跟舊的金額 100 進行一個軋差，利用軋差結果進行清算入賬。

4. 提現失敗返還，根據申請提現生成的提現 id 反查賬戶流水錶,看是否有提現並且沒有提現返還,根據流水金額反向生成流水返還記錄及入賬，保證冪等性。

二. 數據一致性

1. 本地事務

我們按照業務線進行分庫，使得對同一個業務線的操作均落到同一數據源上，利用本地事務進行數據的訪問和更新，從而保持數據一致性。

2. 柔性事務（需冪等）

主要採用了 TCC 模式和事務補償的模式。

T:Try。 完成所有業務檢查,預留出必須業務資源)；

C:Confirm。真正執行業務,不做任何業務檢查,只是用 Try 階段預留的業務資源；

C:Cancel。取消執行業務，釋放資源。

在 Try 這段，是對這個數據進行一個驗證，驗證通過之後，將數據資源進行預留。在 Confirm 階段，只對這個數據直接進行操作，而不進行驗證處理，但是隻操作預留這部分的數據。若是發生取消的操作，將預留的操作返回到賬戶。TCC 模式主要是用於餘額消耗。當商家只能用餘額支付時，先將其餘額支付的金額進行凍結，真正對賬單進行結算時，只使用第一部分凍結的金額，而期間不做任何驗證，訂單完成支付時，對它凍結的這部分金額做真正扣減。如果中間訂單取消了，將凍結的金額進行返還，這樣保證賬戶裏的金額真正發生消耗時是充足的，不用進行反覆的檢查。

事務補償就是操作失敗後的補償。申請提現的時候將賬戶的金額進行扣減，只要申請提現成功，那麼賬戶金額就做扣減。真正提現出金結果，則會通知賬務系統，若出金失敗，賬務系統對提現系統的 ID 進行查詢，按照提現申請時的生成的賬戶生成提現失敗返還流水，按照返還流水更新賬戶金額。

3. 消息隊列

交易系統是通過發送非同步消息到賬務系統，賬務系統處理成功之後，ack 消息；處理失敗則不 ack 消息。利用消息系統重複發送機制再次發送消息，保證賬務系統每條消息均可處理成功。但可能會發生 ack 消息後，消息系統未接收到，那麼就會重複的發送。所以用消息隊列 ack 機制，一定要保證冪等性。

4. 分散式鎖

直接鎖定資源避免了多節點操作引起的數據不一致，只有業務上的硬性要求的時候才用，目前用於控制提現申請的頻率。

以上就是 58 到家賬戶賬務系統的介紹。

作者 | 58 到家 陳丹威

來源 | Ping++ 支付設計大會 ? 北京站現場演講整理

推薦閱讀：