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

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

?

賬務系統(tǒng)概況

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

賬務系統(tǒng)架構

一、支付平臺架構

??

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

交易系統(tǒng)完成后，賬單會推送到賬務系統(tǒng)，賬務系統(tǒng)進行記錄，清算，入賬等。

二、清結算流程

??

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

三、對賬系統(tǒng)

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

四、 監(jiān)控系統(tǒng)

賬務系統(tǒng)最核心的問題是穩(wěn)定，保證數(shù)據(jù)準確，無異常，且能在第一時間發(fā)現(xiàn)問題，盡量降低問題帶來的影響。因此監(jiān)控系統(tǒng)顯得尤為重要。

目前監(jiān)管系統(tǒng)主要用來做異常報警和數(shù)據(jù)埋點。異常報警很好理解，就是系統(tǒng)中如果出現(xiàn)錯誤就會在開發(fā)時打錯誤日志，掃描到有錯誤出現(xiàn)就會通過手機短信發(fā)送給開發(fā)人員，開發(fā)人員就會盡快查詢報警原因和對日常報警是否有數(shù)據(jù)影響，進行相應的處理。

??

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

 

賬務系統(tǒng)的挑戰(zhàn)

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

一、冪等性

大多數(shù)系統(tǒng)會拆分成多個子系統(tǒng)服務,而一個子系統(tǒng)往往會調(diào)用另一個服務,服務之間相互調(diào)用就有可能出現(xiàn)服務器處理完畢后沒有返回結果的情況?？蛻舳藳]有接收到返回結果,就可能重復調(diào)用。冪等性是系統(tǒng)的接口對外的一種承諾(而不是實現(xiàn)), 承諾只要調(diào)用接口成功, 外部多次調(diào)用對系統(tǒng)的影響是一致的。

目前賬戶系統(tǒng)主要是根據(jù)業(yè)務需求做了幾種冪等性：

1、充值時對充值流水號做了唯一的處理，外部調(diào)用充值接口時，傳一個唯一的流水號，判斷這個流水號在系統(tǒng)中存在，就返回，多次調(diào)用，也不會給這個賬戶進行累加充值。

2、對獎懲做了外部唯一 ID 的冪等性，調(diào)用者會傳入唯一 id ,根據(jù)唯一 id 判斷此筆獎懲是否已經(jīng)進行清分入賬。

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

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

4、提現(xiàn)失敗返還，根據(jù)申請?zhí)岈F(xiàn)生成的提現(xiàn) id 反查賬戶流水表,看是否有提現(xiàn)并且沒有提現(xiàn)返還,根據(jù)流水金額反向生成流水返還記錄及入賬，保證冪等性。

二、 數(shù)據(jù)一致性

1、本地事務

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

2、柔性事務（需冪等）

主要采用了 TCC 模式和事務補償?shù)哪Ｊ健?

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

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

C:Cancel。取消執(zhí)行業(yè)務，釋放資源。

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

事務補償就是操作失敗后的補償。申請?zhí)岈F(xiàn)的時候?qū)①~戶的金額進行扣減，只要申請?zhí)岈F(xiàn)成功，那么賬戶金額就做扣減。真正提現(xiàn)出金結果，則會通知賬務系統(tǒng)，若出金失敗，賬務系統(tǒng)對提現(xiàn)系統(tǒng)的 ID 進行查詢，按照提現(xiàn)申請時的生成的賬戶生成提現(xiàn)失敗返還流水，按照返還流水更新賬戶金額。

3、消息隊列

交易系統(tǒng)是通過發(fā)送異步消息到賬務系統(tǒng)，賬務系統(tǒng)處理成功之后，ack 消息；處理失敗則不 ack 消息。利用消息系統(tǒng)重復發(fā)送機制再次發(fā)送消息，保證賬務系統(tǒng)每條消息均可處理成功。但可能會發(fā)生 ack 消息后，消息系統(tǒng)未接收到，那么就會重復的發(fā)送。所以用消息隊列 ack 機制，一定要保證冪等性。

4、分布式鎖

直接鎖定資源避免了多節(jié)點操作引起的數(shù)據(jù)不一致，只有業(yè)務上的硬性要求的時候才用，目前用于控制提現(xiàn)申請的頻率。

以上就是 58 到家賬戶賬務系統(tǒng)的介紹。