轉自： http://mp.weixin.qq.com/s/y2I_EYSLlq_239vZXr0OZQ

本文首先介紹了對賬的概念、基本內容，其次講解了對賬系統中常見問題及解決方法，最后詳細講解了整個對賬系統的流程設計、整體框架。本文所說的對賬是一個通用概念，不針對具體行業，各應用領域可根據實際情況進行調整。

對賬系統簡介

對賬是金融領域中的名詞，對應的學科為大家熟知的會計學。在金融領域中，不僅銀行、基金、第三方支付機構需要對賬，其他任何涉及金融交易的公司/機構都需要對賬，比如商戶業務、信貸業務等。

對賬是指對前一個清算周期的交易信息進行核對，以確認交易信息的一致性和正確性的過程。這是普遍認可的一個概念，可以用一句話總結：確保單個周期內，信息流和現金流的一致。

通過對賬可以保證賬證一致、賬賬一致、賬實一致，三者一致的正確、真實、完整為后續的傭金、分潤等計算提供基礎。對賬的準確性也為系統、人工平賬提供了差錯信息，確保平賬后達到財務一致。

總之，對一個公司來說，通過對賬，可以正確地反映企業的財務狀態，及時發現差錯，確保業務健康發展。

對賬大部分涉及兩方對賬，極少情況下會有三方對賬的情況。三方對賬本身的系統邏輯比較復雜，特別是三方平賬時的差錯處理更加復雜，這里不作討論。

對于沒有虛擬賬戶，只有交易通道類的對賬，有兩種對賬類型：總分對賬和明細對賬。

總分對賬即根據不同的交易通道，把每個交易通道的進出或者單獨的交易類型進行匯總，按照不同交易通道、不同交易類型進行總對總對賬，確保和每個交易通道的進出是一致的，確保每個通道不會有長款或短款的情況。

對大部分系統來說，總分對賬沒有差錯就不用進行明細對賬了。

如果發現總分對賬有差錯，就需要進行明細對賬，將具體差錯信息找出來。明細對賬，顧名思義就是將發生的每一筆交易的詳細信息和交易通道的對賬文件進行逐筆核對，找出是否有不一致的交易。

（圖1 賬戶總余額連續性公式）

對于有虛擬賬戶的對賬，還需要每個清算日對賬戶金額進行核驗檢查。核驗主要包括兩部分：一是賬戶總余額金額連續性檢查，如圖1公式所示；二是記賬準確性檢查。

對賬常見問題及處

（圖2 對賬鏈路示意圖）

對賬一般都是以一方為對賬基準進行軋賬，出現差錯時，通過各種差錯交易。以基準方為準進行處理，最終達到平賬。

對賬的系統順序：首先是金融交易最底層的銀行內部進行對賬以及平賬處理，處理完畢后出具對賬文件；和銀行直接對接的第三方支付機構依此對賬文件進行對賬軋賬，發現差錯時，進行平賬處理；依次往上，直到真正業務場景的用戶。

從中可以發現，離用戶越近的系統拿到對賬文件的時間越晚，等最終整個業務場景鏈對完賬，時間就比較晚了，比如 T+2、T+3，甚至更晚。典型的如消費金融公司，和支付渠道、合作方對完賬，加上平賬處理，基本T+2之后了，如圖2所示。。

（圖3 清算周期時間切分點示意圖）

由于對賬都是基于一個清算周期，清算周期就涉及到一個時間切分點，對賬系統幾乎都會碰到時間差問題。大部分系統都以一個自然日的起始，也就是0點到24點為清算日，但也有比較特殊的清算日規則，比如銀聯和銀行之間的清算日是前一日的23點至當天的23點為一個清算日。

以0至24點一個清算日為例，0點為切分點，本系統發起的交易，到支付通道側，可能已經是下一個清算日，從支付渠道自身來看，本筆交易會在第二天的對賬文件出現，而不是前一個清算日。

如圖3所示。對于這種切分點時間附近無法確認的交易，需要做一個時間窗口，時間窗口內的時間比清算日開始早一些、比清算日結束晚一些。

聯機交易一般有嚴格的時間要求，比如必須在幾秒內應答完畢，大于幾秒就會造成客戶體驗差，流失大量客戶。

而對賬是典型的批量處理任務，幾秒或者幾分鐘完成沒有太大影響，但也不代表時間太長，幾個小時就明顯太長，會嚴重影響賬務問題，無法開展日常業務。

對賬是典型的批量處理任務，需要批量調度平臺進行調度。對于比較復雜的調度邏輯（比如依賴關系調度、靈活觸發、運營界面等），需要高可用、高并發、高伸縮的分布式調度系統，可以考慮用Zeus、Quarts、Elastic-Job、Azkaban等進行定制化開發。

下面重點介紹一下明細對賬以及技術實現方案。

（圖4 明細對賬總體流程）

明細對賬的總體流程如圖4所示，包括對賬文件下載、文件預處理、軋賬、平帳，以及運營平臺對平帳過程的監控、預警，下面進行詳細介紹。

對賬文件下載

對賬文件一般由對賬對手方根據數據庫的交易記錄產生，并放置和對賬方約定的地方，比如文件服務器、FTP服務器等。對賬方根據事先約定的方式，獲取對賬文件，比如通過HTTP/HTTPS下載或者FTP/SFTP拉取。

對賬預處理

為了安全性、客戶保密性、防篡改，會對對賬文件進行加密處理，常用的有3DES、AES等對稱加密或者RSA非對稱加密，以及MD5、SHA1、SHA512等摘要信息，還有各種簽名機制。

獲取到對賬文件后，并不能立即進行對賬，需要首先按特定安全機制進行解密，另外也需要把對賬文件格式轉換成內部系統方便處理的格式。這些都是軋賬前的預處理。

軋帳

（圖5 代收交易軋帳示意圖）

軋帳是會計科目流程之一，定期或者企業需要時，核對總賬與明細賬，每日記賬是否一致。軋帳是對賬最核心的流程，用來確認雙方或多方的賬目是否一致，不一致的情況下，有哪些差錯。

軋帳的正確與否，影響到后續的差錯處理即平帳。以向用戶代收為例，軋帳的流程如圖5所示。

為了確認交易記錄的標準，需要雙方約定，哪個或者哪些要素可以唯一確定一筆交易，比如訂單號，有時也會加上時間。

在具體對賬的內容上，一般只需比對金額即可，某些情況下為了完備性，還會校對清算日、客戶信息等其他明細數據。

某些非金額因素會影響到傭金計算、多方分潤等，所以也需要進行軋賬確認。

技術是為商業目標服務，業務發展到什么規模，就有什么樣的技術與之匹配。所以，對賬系統沒有標準完美的技術解決方案，不同的業務場景會有不同的特性需求。

盡管行業、業務規模不同導致技術方案有一定的差異性，但是差異是相對的，其中還有很多共性。下面所討論的軋賬技術方案是較通用的，當然還有很多技術細節，不展開討論。

依次讀取預處理后的對賬文件，根據交易標識在數據庫中找出對應的記錄，進行比對，檢查是否一致。

此種軋帳的方式非常簡單，容易理解，程序實現也比較簡單。缺點也顯而易見，支持數據量少，如果交易量大，會導致內存不足，并且大量數據庫查詢，會耗盡數據庫資源，對聯機交易有影響。

另外，因為是串行處理，在交易量大時，會大大延長軋帳時間，影響正常業務的進行。

改進措施

將對賬文件按一定規則劃分為小文件，確保每次只處理記錄數有限的文件；

按對賬文件的記錄數進行劃分，由不同的節點進行處理，比如1-n由節點1處理，(n+1)-2n由節點2處理，(i-1)n+1-i*n由節點i處理，…充分利用分布式系統進行處理；

為了減少對聯機交易的影響，可以在日切之后將交易記錄導入到專門的對賬庫或者歷史庫進行對賬；

在數據庫中，新增和對賬文件結構一致的對賬表，將預處理后的對賬文件按記錄逐條導入到對賬表中。利用數據庫提供的join, left join,right join, case when等SQL語法進行軋帳。

比如SQL：select case when a.amt<>b.amt then 1 else 0 end from a join b on a.order_no=b.order_no，可以把金額不一致的找出來。

select case when a.amt is null then 1 else 0 end from a join b on a.order_no=b.order_no，可以把本地系統中不存在的交易的找出來。其他以此類推，不一一介紹。

這種軋帳邏輯放在數據庫，簡單方便，后續方便擴展；對賬對手方的數據都存儲在數據庫，可以非常容易可視化和排查問題。

缺點是：交易量大時，導入量大，數據預熱慢，數據庫性能很容易成為瓶頸；所有的計算節點集中于數據庫，無法利用分布式。

改進措施

批量導入數據庫；

根據軋帳標識進行分表分庫處理，并進行匯總。

Redis是高性能的key-value數據庫，支持5種基本類型(String, List, Set, ZSet, Hash)以及5種基本類型的擴展。對于Set數據類型，天然的支持交集、差集、并集等集合運算。

將預處理過的對賬文件按軋帳標識和比對元素加載到Redis的一個Set A，本系統的交易記錄也一并加載到Redis的另外一個Set B。Set A和Set B的交集即為對賬對平的交易。

Set A-Set B差集并不是多的記錄，還需要將每個元素和Set B-Set A的差集進行查找，如果有軋帳標識一樣但比對元素不一樣的，即為差錯交易；如果沒有軋帳標識一樣的元素，才能判斷是多的記錄。同理，可以找出少的記錄。

這種借助于Redis軋帳，是一種純內存計算，預熱快，速度快，充分利用Redis的成熟計算類型，沒有復雜的程序邏輯處理，避免出錯。但缺點是計算機內存有限，不能支持海量對賬數據。

改進措施

按一定規則，進行數據分片，不同的數據按照軋賬標識分片到不同的Redis，最后再進行匯總，但同時也增加了軋帳復雜性。

如果把軋帳進行數學模型抽象的話，可以抽象為一個典型的算法問題：構建2個無重復元素的集合，按照一定比對規則找出2個集合的差集、交集，對差集和交集的元素屬性進行計算比對，找出差異性。

通過抽象后，我們可以看出，有很多實現方法，比如Java JDK提供的集合計算Collections、擅長搜索的Elastic Search等。

這種實現方式需要視具體情況進行分析，有些實現需要花大量的時間和邏輯在數據預熱上，有些實現會導致匯總數據的邏輯復雜化。

總之，對賬系統涉及公司的賬務會計核心，盡早建立完備的對賬系統，可以推動更加精細化掌握業務情況，特別是互聯網金融公司。

在對賬系統落地時，可以綜合考慮本文提出的方案，找出適合公司業務發展的技術方案，盡量使用成熟技術解決業務問題，減少技術風險性。

本文的下半部分將講述如何處理海量數據的對賬，以及平帳/差錯處理和虛擬賬戶對賬，敬請期待。

作者介紹

王興建

現任上海秦蒼（買單俠）信息科技有限公司軟件架構師，加入秦蒼之前，曾在中國銀聯、證通任職。

專注于Java Core、NoSQL、分布式服務框架等技術領域，對移動支付、客戶認證、紅包、虛擬賬戶、信貸等業務領域有豐富的經驗，擅長將成熟技術應用于業務。

目前主要負責秦蒼運營商合作業務的架構設計，以及技術在業務中的落地工作。

總結

以上是生活随笔為你收集整理的通用对账系统介绍与设计(上)的全部內容，希望文章能夠幫你解決所遇到的問題。

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