我們聊聊對帳系統該如何設計

在互聯網行業中只要涉及到支付，必然就會有對帳的需求，幾乎全部互聯網公司的業務中多多少少的都會涉及到支付，大一點的公司甚至都標配有了本身的第三方支付公司，所以對帳具備廣泛性。對帳系統是支付體系中最重要的一環，也是保證交易、資金安全的最後一道防線。在大多數的互聯網公司中，通常都會有獨立的對帳系統來處理，好比：電商平臺、互聯網金融、第三方支付公司等。

對帳是支付系統中的一環，所以在對帳前咱們先了解一下相關的業務知識

業務知識

什麼是對帳

傳統的對帳就是覈對帳目，是指在會計覈算中，爲保證帳簿記錄正確可靠，對帳簿中的有關數據進行檢查和核對的工做。在銀行或者第三方支付中，對帳實際上是對必定週期內的交易進行雙方確認的過程，通常都是在次日銀行或者第三方支付公司對前一日交易進行清分，生成對帳單供平臺商戶下載，並將應結算款結算給平臺商戶。在往下一層，在互聯網金融行業或者電商行業中，對帳其實就是確認在固定週期內和支付提供方（銀行和第反方支付）的交易、資金的正確性，保證雙方的交易、資金一致正確。

廣義的對帳，全部跨應用的數據交互，理論上都應該進行對帳。因此對帳也能夠分爲信息流對帳，資金流對帳。信息流對帳也通常用在本身內部系統的對帳，好比支付系統的支付數據和業務系統的業務數據進行對帳，保證資金交易和業務交易的一致性。資金流對帳也就是支付系統和銀行或者第三方支付系統之間的資金交易對帳。

對帳方式

• 單向對帳：通常拿第三方支付機構或銀行流水，與本身系統進行對帳，防止出現掉單問題；
• 雙向對帳：兩個應用間的流水進行雙向覈對，如訂單與財務系統，既要保證財務系統支付成功的記錄，訂單系統也是成功的；也要確保訂單系統記錄成功的記錄，財務系統也成功。

咱們通常採用雙向對帳的方式進行對帳

對帳相關的問題

不一樣系統日切點不一致問題：滾動對帳
差錯處理：補帳，補償（退款）

相關概念

軋賬和平賬

每一筆交易，都要作到各參與者的記錄可以吻合，沒有誤差。對帳系統的工做，是發現有差別的記錄，即軋賬；而後經過人工或者自動的方式，解決這些差別，即平賬。

長款和漏單

在以平臺交易爲基準的狀況下和銀行對帳，發現週期內的交易，平臺有此訂單而第三方支付中沒有訂單，成爲平臺長款。平臺長款通常是因爲用戶在支付的時候跨天的狀況，好比用戶在23:58分建立了訂單，在次日的凌晨00:03分進行了支付。在以銀行交易爲基準的狀況下對帳，銀行有此訂單而平臺無此訂單，即爲平臺漏單。平臺漏單不多見，通常直接轉人工處理。

帳戶體系

在通常的支付體系中會分爲登陸帳戶和支付帳戶，支付帳戶指用戶在支付系統中用於交易的資金全部者權益的憑證；登陸帳號指用戶在系統中登陸的憑證和我的信息。一個用戶能夠有多個登陸帳戶，一個登陸帳戶能夠有多個支付帳戶，好比零錢帳戶、儲值卡帳戶等。通常來講，支付帳戶不會在多個登陸帳戶之間共用。對帳的交易通常都是支付帳戶參與交易。

交易與帳戶

帳戶設置，通常是從交易開始的。 交易的實現必須有帳戶的支持，帳戶是交易的基本構成元素。 從支付系統的角度，交易中涉及到的資金流是資金從一個帳戶流向另外一個帳戶。 發起交易的一方，被稱之爲交易主體，他能夠是一我的，也能夠是一個機構。

清算和結算

清算主要是指不一樣銀行間的貨幣收付，能夠認爲是結算進行以前，發起行和接收行對支付指令的發送、接收、覈對確認，其結果是全面交換結算工具和支付信息，並創建最終結算頭寸。

結算是指將清算過程產生的待結算頭寸分別在發起行、接收行進行相應的會計處理，完成資金轉移，並通知收付雙方的過程。當前，大多數銀行結算業務的完成主要經過兩類帳戶：一是銀行間互相開立的代理帳戶，二是開立在央行、獨立金融機構如銀聯、或者第三方支付機構的帳戶。

清算：計算各方應收應付錢款的時間與金額。結算：根據清算的結果在指定的時間對各方進行實際的資金轉移操做

資金池

用戶備付資金（如充值）統一放在企業的銀行帳戶中，企業能夠隨意支配這些資金，即爲資金池。與之對應的是第三方託管，用戶備付資金是放在企業在第三方支付機構爲用戶開設的虛擬帳戶中，企業沒法隨意取出這些資金。如今互聯網金融全面要求接入銀行存管，就是銀行會爲每一個用戶建立一個資金帳戶來保護用戶的資金，互聯金融公司不能隨意劃撥這些資金帳戶中的金額。

對帳系統

對帳設計

對帳系統的設計階段，將對帳系統分爲四個模塊，每一個模塊的負責本身的職能。

• 文件獲取模塊：下載或者讀取各渠道對帳文件
• 文件解析模塊：建立不一樣的解析模板，根據渠道和文件類型獲取對應的解析模板進行解析
• 對帳處理模塊：對帳的業務邏輯處理
• 差錯處理模塊：處理差錯池中的訂單

通常會設計一個定時任務，天天固定的時間點觸發，定時驅動調度類分別調用四個模塊來處理對帳。也有的銀行會主動的推送對帳單，再經過http回調來觸發對帳流程。

對帳算法

1、流程：

一、從上游渠道（銀行、銀聯等金融機構）獲取對帳文件，程序逐行解析入庫；
二、在程序處理中，以上游對帳文件的表爲基準，程序逐行讀取並與咱們系統的交易記錄對比帳務記錄（有帳務系統狀況下，合理方案應該是於帳務記錄）對比，查找出差別記錄；
三、以咱們系統的交易記錄對比帳務記錄爲基準，程序逐行讀取與上游對帳文件對比，查找出差別記錄。

2、缺陷：

一、對帳過程當中查詢相關數據，若是數據量巨大，對數據庫性能影響較大，並且對帳邏輯擴展極爲麻煩；
二、逐行比對算法效率較低，但算法上並沒有好的優化餘地。若是採用數據庫INTERSECT、MINUS對數據庫壓力也高；
三、在業務量大的狀況下（例若有上百家上游渠道須要對，每一家都有幾十萬條交易記錄），對帳服務器及數據庫服務器負荷較高。即使採用讀寫分離，對帳時候使用讀庫，壓力同樣很大；
四、導入批量文件，逐行入庫效率較爲低下（每一次都須要創建網絡鏈接、關閉鏈接）。

3、改進：

一、涉及網絡傳輸的，儘可能採用批量方式操做，減小網絡消耗及時間消耗；
二、使用Redis等NOSQL數據庫，下降數據庫服務器的壓力。同時在擴展上也容易，一臺Redis服務器不夠，能夠無限制增長用於對帳用的服務器；
三、使用Redis的set集合的sdiff功能，利用Redis sdiff算法的高性能，比對上游記錄和我方記錄的差別。

對帳流程

一、下載對帳單

大多數銀行都要求接入方提供ftp服務，銀行定時將對帳單推送到接入方提供的ftp服務器上面；還有一部分銀行會提供對帳單的下載服務，經過ftp/http的都有，ftp方式居多；另外網銀的對帳單比較特殊，通常都須要結算登陸網銀的後臺管理系統中，手動下載，結算下載完對帳單後在導入到對帳系統。

技術實現上能夠作成工廠模式，不一樣的支付渠道有不一樣的下載類，若是是http接口將文件寫入到對帳單，若是是ftp服務器，將服務器中的對帳單下載到本地帶解析的目錄中。主要涉及的代碼ftp工具類、http(s)工具類，相關IO讀寫。

技術選型上，HTTP(S)用apache httpclient便可實現連接池和斷點續傳， FTP也可使用Apache Commons Net API。 但無論是哪個，都須要設置重試次數和連接超時間。重試次數和間隔的設置須要當心，重試太頻繁，容易把服務器打死.；時間間隔太大，又會阻塞後續處理步驟。5～10分鐘是一個合適的重試間隔區間。

二、建立批次

建立批次一方面是爲了防止重複對帳，另外一方面須要在對帳結束的時候將對帳的結果信息存儲到批次中。

三、解析文件

解析文件主要是將下載的對帳文件解析成咱們能夠對帳的數據類型而且入庫。解析的文件不一樣渠道有不一樣的類型，所以也能夠設計成不一樣的解析模板，使用工廠模式將不一樣格式的文件解析成能夠對帳的統一數據類型。解析的文件類型通常包括：json、text、cvs、excle等，另外部分銀行會對帳單作加密或者提供zip打包的格式，這裏就須要額外開發zip工具類和加解密工具類進行處理。

對帳文件中包含的主要信息有：商戶訂單號、交易流水號、交易時間、支付時間、付款方、交易金額、交易類型、交易狀態這些字段。

四、對帳處理

對帳處理也是對帳的核心邏輯，具體分爲如下的幾個步驟來實現：

• 查詢平臺全部交易成功的訂單
• 查詢平臺全部的交易訂單
• 查詢平臺緩存池中的數據
• 查詢銀行交易成功的訂單
• 開始以平臺的數據爲準對帳,平臺長款記入緩衝池
• 開始以銀行通道的數據爲準對帳

以平臺訂單爲基準對帳邏輯：以平臺全部交易成功的訂單爲基準，遍歷銀行訂單的全部數據，找出訂單號相同的訂單，對比訂單的金額、手續費是否一致。若是一致跳過；若是不一致，平臺訂單進入差錯池；若是在銀行訂單中沒有找到此筆交易，訂單進入緩存池，記錄平臺長款。同時統計對帳相關金額和訂單數。

以銀行訂單爲基準對帳邏輯：以銀行的交易數據爲基準，遍歷全部平臺的交易（包括未成功的訂單），找出訂單號相同但支付狀態不一致的訂單，在進行對比金額存入差錯池。若是沒有在平臺的交易中找到此訂單，再從緩存池中遍歷查找，找到對應的平臺訂單驗證金額是否一致，不一致進入差錯池。若是在緩存池匯中依然沒有找到對應的訂單，直接進入差錯池，記錄平臺漏單。同時統計對帳相關金額和訂單數。

五、對帳統計

根據對帳處理中，統計的相關信息包括：對帳完成時間、對帳是否成功、平帳的金額和訂單數、差錯的金額和訂單數、緩存池金額和訂單數等。

六、差錯處理

在通常系統中，差錯處理分爲兩種，一種人工來處理，一種系統自動來處理。

主要有以下狀況：

• 本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的異步通知致使。 通常處理是將本地狀態修改成已支付，並作響應的後續處理，好比通知業務方等。
• 本地已支付，支付渠道已支付，可是金額不一樣，這個須要人工覈查。
• 本地已支付，可是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。在排除跨日因素外，這種狀況很是少見，須要瞭解具體緣由後作處理。