在互聯(lián)網(wǎng)行業(yè)中只要涉及到支付，必然就會(huì)有對(duì)賬的需求，幾乎所有互聯(lián)網(wǎng)公司的業(yè)務(wù)中多多少少的都會(huì)涉及到支付，大一點(diǎn)的公司甚至都標(biāo)配有了自己的第三方支付公司，因此對(duì)賬具有普遍性。對(duì)賬系統(tǒng)是支付體系中最重要的一環(huán)，也是保證交易、資金安全的***一道防線。在大多數(shù)的互聯(lián)網(wǎng)公司中，一般都會(huì)有獨(dú)立的對(duì)賬系統(tǒng)來(lái)處理，比如：電商平臺(tái)、互聯(lián)網(wǎng)金融、第三方支付公司等。

[[195500]]

對(duì)賬是支付系統(tǒng)中的一環(huán)，因此在對(duì)賬前我們先了解一下相關(guān)的業(yè)務(wù)知識(shí)

業(yè)務(wù)知識(shí)

什么是對(duì)賬

傳統(tǒng)的對(duì)賬就是核對(duì)賬目，是指在會(huì)計(jì)核算中，為保證賬簿記錄正確可靠，對(duì)賬簿中的有關(guān)數(shù)據(jù)進(jìn)行檢查和核對(duì)的工作。在銀行或者第三方支付中，對(duì)賬其實(shí)是對(duì)一定周期內(nèi)的交易進(jìn)行雙方確認(rèn)的過(guò)程，一般都是在第二天銀行或者第三方支付公司對(duì)前一日交易進(jìn)行清分，生成對(duì)賬單供平臺(tái)商戶下載，并將應(yīng)結(jié)算款結(jié)算給平臺(tái)商戶。在往下一層，在互聯(lián)網(wǎng)金融行業(yè)或者電商行業(yè)中，對(duì)賬其實(shí)就是確認(rèn)在固定周期內(nèi)和支付提供方(銀行和第反方支付)的交易、資金的正確性，保證雙方的交易、資金一致正確。

廣義的對(duì)賬，所有跨應(yīng)用的數(shù)據(jù)交互，理論上都應(yīng)該進(jìn)行對(duì)賬。所以對(duì)賬也可以分為信息流對(duì)賬，資金流對(duì)賬。信息流對(duì)賬也一般用在自己內(nèi)部系統(tǒng)的對(duì)賬，比如支付系統(tǒng)的支付數(shù)據(jù)和業(yè)務(wù)系統(tǒng)的業(yè)務(wù)數(shù)據(jù)進(jìn)行對(duì)賬，保證資金交易和業(yè)務(wù)交易的一致性。資金流對(duì)賬也就是支付系統(tǒng)和銀行或者第三方支付系統(tǒng)之間的資金交易對(duì)賬。

對(duì)賬方式

• 單向?qū)~：一般拿第三方支付機(jī)構(gòu)或銀行流水，與自己系統(tǒng)進(jìn)行對(duì)賬，防止出現(xiàn)掉單問(wèn)題;
• 雙向?qū)~：兩個(gè)應(yīng)用間的流水進(jìn)行雙向核對(duì)，如訂單與財(cái)務(wù)系統(tǒng)，既要保證財(cái)務(wù)系統(tǒng)支付成功的記錄，訂單系統(tǒng)也是成功的;也要確保訂單系統(tǒng)記錄成功的記錄，財(cái)務(wù)系統(tǒng)也成功。

我們一般采用雙向?qū)~的方式進(jìn)行對(duì)賬

對(duì)賬相關(guān)的問(wèn)題

不同系統(tǒng)日切點(diǎn)不一致問(wèn)題：滾動(dòng)對(duì)賬

差錯(cuò)處理：補(bǔ)賬，補(bǔ)償(退款)

相關(guān)概念

軋帳和平帳

每一筆交易，都要做到各參與者的記錄能夠吻合，沒(méi)有偏差。對(duì)賬系統(tǒng)的工作，是發(fā)現(xiàn)有差異的記錄，即軋帳;然后通過(guò)人工或者自動(dòng)的方式，解決這些差異，即平帳。

長(zhǎng)款和漏單

在以平臺(tái)交易為基準(zhǔn)的情況下和銀行對(duì)賬，發(fā)現(xiàn)周期內(nèi)的交易，平臺(tái)有此訂單而第三方支付中沒(méi)有訂單，成為平臺(tái)長(zhǎng)款。平臺(tái)長(zhǎng)款一般是由于用戶在支付的時(shí)候跨天的情況，比如用戶在23:58分創(chuàng)建了訂單，在第二天的凌晨00:03分進(jìn)行了支付。在以銀行交易為基準(zhǔn)的情況下對(duì)賬，銀行有此訂單而平臺(tái)無(wú)此訂單，即為平臺(tái)漏單。平臺(tái)漏單很少見(jiàn)，一般直接轉(zhuǎn)人工處理。

賬戶體系

在一般的支付體系中會(huì)分為登錄賬戶和支付賬戶，支付賬戶指用戶在支付系統(tǒng)中用于交易的資金所有者權(quán)益的憑證;登錄賬號(hào)指用戶在系統(tǒng)中登錄的憑證和個(gè)人信息。一個(gè)用戶可以有多個(gè)登錄賬戶，一個(gè)登錄賬戶可以有多個(gè)支付賬戶，比如零錢(qián)賬戶、儲(chǔ)值卡賬戶等。一般來(lái)說(shuō)，支付賬戶不會(huì)在多個(gè)登錄賬戶之間共用。對(duì)賬的交易一般都是支付賬戶參與交易。

交易與賬戶

賬戶設(shè)置，一般是從交易開(kāi)始的。 交易的實(shí)現(xiàn)必須有賬戶的支持，賬戶是交易的基本構(gòu)成元素。 從支付系統(tǒng)的角度，交易中涉及到的資金流是資金從一個(gè)賬戶流向另一個(gè)賬戶。 發(fā)起交易的一方，被稱之為交易主體，他可以是一個(gè)人，也可以是一個(gè)機(jī)構(gòu)。

清算和結(jié)算

清算主要是指不同銀行間的貨幣收付，可以認(rèn)為是結(jié)算進(jìn)行之前，發(fā)起行和接收行對(duì)支付指令的發(fā)送、接收、核對(duì)確認(rèn)，其結(jié)果是全面交換結(jié)算工具和支付信息，并建立最終結(jié)算頭寸。

結(jié)算是指將清算過(guò)程產(chǎn)生的待結(jié)算頭寸分別在發(fā)起行、接收行進(jìn)行相應(yīng)的會(huì)計(jì)處理，完成資金轉(zhuǎn)移，并通知收付雙方的過(guò)程。當(dāng)前，大多數(shù)銀行結(jié)算業(yè)務(wù)的完成主要通過(guò)兩類賬戶：一是銀行間互相開(kāi)立的代理賬戶，二是開(kāi)立在央行、獨(dú)立金融機(jī)構(gòu)如銀聯(lián)、或者第三方支付機(jī)構(gòu)的賬戶。

清算：計(jì)算各方應(yīng)收應(yīng)付錢(qián)款的時(shí)間與金額。結(jié)算：根據(jù)清算的結(jié)果在指定的時(shí)間對(duì)各方進(jìn)行實(shí)際的資金轉(zhuǎn)移操作

資金池

用戶備付資金(如充值)統(tǒng)一放在企業(yè)的銀行賬戶中，企業(yè)可以隨意支配這些資金，即為資金池。與之對(duì)應(yīng)的是第三方托管，用戶備付資金是放在企業(yè)在第三方支付機(jī)構(gòu)為用戶開(kāi)設(shè)的虛擬賬戶中，企業(yè)無(wú)法隨意取出這些資金?，F(xiàn)在互聯(lián)網(wǎng)金融全面要求接入銀行存管，就是銀行會(huì)為每個(gè)用戶創(chuàng)建一個(gè)資金賬戶來(lái)保護(hù)用戶的資金，互聯(lián)金融公司不能隨意劃撥這些資金賬戶中的金額。

對(duì)賬系統(tǒng)

對(duì)賬設(shè)計(jì)

對(duì)賬系統(tǒng)的設(shè)計(jì)階段，將對(duì)賬系統(tǒng)分為四個(gè)模塊，每個(gè)模塊的負(fù)責(zé)自己的職能。

• 文件獲取模塊：下載或者讀取各渠道對(duì)賬文件
• 文件解析模塊：創(chuàng)建不同的解析模板，根據(jù)渠道和文件類型獲取對(duì)應(yīng)的解析模板進(jìn)行解析
• 對(duì)賬處理模塊：對(duì)賬的業(yè)務(wù)邏輯處理
• 差錯(cuò)處理模塊：處理差錯(cuò)池中的訂單

一般會(huì)設(shè)計(jì)一個(gè)定時(shí)任務(wù)，每天固定的時(shí)間點(diǎn)觸發(fā)，定時(shí)驅(qū)動(dòng)調(diào)度類分別調(diào)用四個(gè)模塊來(lái)處理對(duì)賬。也有的銀行會(huì)主動(dòng)的推送對(duì)賬單，再通過(guò)http回調(diào)來(lái)觸發(fā)對(duì)賬流程。

對(duì)賬算法

***程：

1、從上游渠道(銀行、銀聯(lián)等金融機(jī)構(gòu))獲取對(duì)賬文件，程序逐行解析入庫(kù);

2、在程序處理中，以上游對(duì)賬文件的表為基準(zhǔn)，程序逐行讀取并與我們系統(tǒng)的交易記錄對(duì)比賬務(wù)記錄(有賬務(wù)系統(tǒng)情況下，合理方案應(yīng)該是于賬務(wù)記錄)對(duì)比，查找出差異記錄;

3、以我們系統(tǒng)的交易記錄對(duì)比賬務(wù)記錄為基準(zhǔn)，程序逐行讀取與上游對(duì)賬文件對(duì)比，查找出差異記錄。

二、缺陷：

1、對(duì)賬過(guò)程中查詢相關(guān)數(shù)據(jù)，如果數(shù)據(jù)量巨大，對(duì)數(shù)據(jù)庫(kù)性能影響較大，而且對(duì)賬邏輯擴(kuò)展極為麻煩;

2、逐行比對(duì)算法效率較低，但算法上并無(wú)好的優(yōu)化余地。如果采用數(shù)據(jù)庫(kù)INTERSECT、MINUS對(duì)數(shù)據(jù)庫(kù)壓力也高;

3、在業(yè)務(wù)量大的情況下(例如有上百家上游渠道需要對(duì)，每一家都有幾十萬(wàn)條交易記錄)，對(duì)賬服務(wù)器及數(shù)據(jù)庫(kù)服務(wù)器負(fù)荷較高。即便采用讀寫(xiě)分離，對(duì)賬時(shí)候使用讀庫(kù)，壓力一樣很大;

4、導(dǎo)入批量文件，逐行入庫(kù)效率較為低下(每一次都需要建立網(wǎng)絡(luò)連接、關(guān)閉連接)。

三、改進(jìn)：

1、涉及網(wǎng)絡(luò)傳輸?shù)?，盡量采用批量方式操作，減少網(wǎng)絡(luò)消耗及時(shí)間消耗;

2、使用Redis等NOSQL數(shù)據(jù)庫(kù)，降低數(shù)據(jù)庫(kù)服務(wù)器的壓力。同時(shí)在擴(kuò)展上也容易，一臺(tái)Redis服務(wù)器不夠，可以***制增加用于對(duì)賬用的服務(wù)器;

3、使用Redis的set集合的sdiff功能，利用Redis sdiff算法的高性能，比對(duì)上游記錄和我方記錄的差異。

對(duì)賬流程

1、下載對(duì)賬單

大多數(shù)銀行都要求接入方提供ftp服務(wù)，銀行定時(shí)將對(duì)賬單推送到接入方提供的ftp服務(wù)器上面;還有一部分銀行會(huì)提供對(duì)賬單的下載服務(wù)，通過(guò)ftp/http的都有，ftp方式居多;另外網(wǎng)銀的對(duì)賬單比較特殊，一般都需要結(jié)算登錄網(wǎng)銀的后臺(tái)管理系統(tǒng)中，手動(dòng)下載，結(jié)算下載完對(duì)賬單后在導(dǎo)入到對(duì)賬系統(tǒng)。

技術(shù)實(shí)現(xiàn)上可以做成工廠模式，不同的支付渠道有不同的下載類，如果是http接口將文件寫(xiě)入到對(duì)賬單，如果是ftp服務(wù)器，將服務(wù)器中的對(duì)賬單下載到本地帶解析的目錄中。主要涉及的代碼ftp工具類、http(s)工具類，相關(guān)IO讀寫(xiě)。

技術(shù)選型上，HTTP(S)用apache httpclient即可實(shí)現(xiàn)鏈接池和斷點(diǎn)續(xù)傳， FTP也可以使用Apache Commons Net API。 但不管是哪一個(gè)，都需要設(shè)置重試次數(shù)和鏈接超時(shí)間。重試次數(shù)和間隔的設(shè)置需要小心，重試太頻繁，容易把服務(wù)器打死.;時(shí)間間隔太大，又會(huì)阻塞后續(xù)處理步驟。5～10分鐘是一個(gè)合適的重試間隔區(qū)間。

2、創(chuàng)建批次

創(chuàng)建批次一方面是為了防止重復(fù)對(duì)賬，另一方面需要在對(duì)賬結(jié)束的時(shí)候?qū)?duì)賬的結(jié)果信息存儲(chǔ)到批次中。

3、解析文件

解析文件主要是將下載的對(duì)賬文件解析成我們可以對(duì)賬的數(shù)據(jù)類型并且入庫(kù)。解析的文件不同渠道有不同的類型，因此也可以設(shè)計(jì)成不同的解析模板，使用工廠模式將不同格式的文件解析成可以對(duì)賬的統(tǒng)一數(shù)據(jù)類型。解析的文件類型一般包括：json、text、cvs、excle等，另外部分銀行會(huì)對(duì)賬單做加密或者提供zip打包的格式，這里就需要額外開(kāi)發(fā)zip工具類和加解密工具類進(jìn)行處理。

對(duì)賬文件中包含的主要信息有：商戶訂單號(hào)、交易流水號(hào)、交易時(shí)間、支付時(shí)間、付款方、交易金額、交易類型、交易狀態(tài)這些字段。

4、對(duì)賬處理

對(duì)賬處理也是對(duì)賬的核心邏輯，具體分為以下的幾個(gè)步驟來(lái)實(shí)現(xiàn)：

• 查詢平臺(tái)所有交易成功的訂單
• 查詢平臺(tái)所有的交易訂單
• 查詢平臺(tái)緩存池中的數(shù)據(jù)
• 查詢銀行交易成功的訂單
• 開(kāi)始以平臺(tái)的數(shù)據(jù)為準(zhǔn)對(duì)賬,平臺(tái)長(zhǎng)款記入緩沖池
• 開(kāi)始以銀行通道的數(shù)據(jù)為準(zhǔn)對(duì)賬

以平臺(tái)訂單為基準(zhǔn)對(duì)賬邏輯：以平臺(tái)所有交易成功的訂單為基準(zhǔn)，遍歷銀行訂單的所有數(shù)據(jù)，找出訂單號(hào)相同的訂單，對(duì)比訂單的金額、手續(xù)費(fèi)是否一致。如果一致跳過(guò);如果不一致，平臺(tái)訂單進(jìn)入差錯(cuò)池;如果在銀行訂單中沒(méi)有找到此筆交易，訂單進(jìn)入緩存池，記錄平臺(tái)長(zhǎng)款。同時(shí)統(tǒng)計(jì)對(duì)賬相關(guān)金額和訂單數(shù)。

以銀行訂單為基準(zhǔn)對(duì)賬邏輯：以銀行的交易數(shù)據(jù)為基準(zhǔn)，遍歷所有平臺(tái)的交易(包括未成功的訂單)，找出訂單號(hào)相同但支付狀態(tài)不一致的訂單，在進(jìn)行對(duì)比金額存入差錯(cuò)池。如果沒(méi)有在平臺(tái)的交易中找到此訂單，再?gòu)木彺娉刂斜闅v查找，找到對(duì)應(yīng)的平臺(tái)訂單驗(yàn)證金額是否一致，不一致進(jìn)入差錯(cuò)池。如果在緩存池匯中依然沒(méi)有找到對(duì)應(yīng)的訂單，直接進(jìn)入差錯(cuò)池，記錄平臺(tái)漏單。同時(shí)統(tǒng)計(jì)對(duì)賬相關(guān)金額和訂單數(shù)。

5、對(duì)賬統(tǒng)計(jì)

根據(jù)對(duì)賬處理中，統(tǒng)計(jì)的相關(guān)信息包括：對(duì)賬完成時(shí)間、對(duì)賬是否成功、平賬的金額和訂單數(shù)、差錯(cuò)的金額和訂單數(shù)、緩存池金額和訂單數(shù)等。

6、差錯(cuò)處理

在一般系統(tǒng)中，差錯(cuò)處理分為兩種，一種人工來(lái)處理，一種系統(tǒng)自動(dòng)來(lái)處理。

主要有如下情況：

• 本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發(fā)的異步通知導(dǎo)致。 一般處理是將本地狀態(tài)修改為已支付，并做響應(yīng)的后續(xù)處理，比如通知業(yè)務(wù)方等。
• 本地已支付，支付渠道已支付，但是金額不同，這個(gè)需要人工核查。
• 本地已支付，但是支付渠道中無(wú)記錄;或者本地?zé)o記錄，支付渠道有記錄。在排除跨日因素外，這種情況非常少見(jiàn)，需要了解具體原因后做處理。

示例代碼

網(wǎng)上的對(duì)賬系統(tǒng)的開(kāi)源代碼不是很多，但有一家還不錯(cuò)：龍果支付。龍果支付中有比較完整的對(duì)賬流程，代碼中以微信、支付寶的對(duì)賬單為例寫(xiě)了對(duì)賬的流程，大家可以參考。

roncoo-pay 

【本文為51CTO專欄作者“純潔的微笑”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文