上篇文章聊到了對賬系統(tǒng)業(yè)務邏輯以及千萬數(shù)據(jù)集對賬系統(tǒng)存在的難點，這篇文章就來聊下千萬級數(shù)據(jù)集下對賬系統(tǒng)實現(xiàn)方案。

首先我們先來看下對賬整體時序圖，先有個印象：

下面整篇文章將會圍繞上面時序圖開始講解，由于文章篇幅過長，所以文章將會拆分成上下兩部分。

數(shù)據(jù)平臺

上次文章中提到，千萬級數(shù)據(jù)需要使用 Hive，Spark等相關大數(shù)據(jù)技術，這就離不開大數(shù)據(jù)平臺的技術支持。

簡單聊下我們這邊大數(shù)據(jù)平臺DP （Data Platform），它提供用戶大數(shù)據(jù)離線任務開發(fā)所需要的環(huán)境、工具以及數(shù)據(jù)，具有入口統(tǒng)一性、一站式、簡化hadoop本身的復雜性、數(shù)據(jù)安全等特點。

DP 平臺提供功能如下：

• 數(shù)據(jù)雙向離線同步，MySQL 與 Hive 互相同步
• 大數(shù)據(jù)離線計算，支持SQL（SparkSQL/HiveSQL/Presto)形式處理各類的數(shù)據(jù)清洗、轉化、聚合操作，也支持使用MapReduce、Spark等形式，處理比較復雜的計算場景
• 即時的SQL查詢，允許用戶即時的執(zhí)行SQL、查看執(zhí)行的日志和結果數(shù)以及進行結果數(shù)據(jù)的可視化分析
• 數(shù)據(jù)報表

那本篇文章不會涉及具體的大數(shù)據(jù)技術相關的實現(xiàn)細節(jié),相關原理（主要是咱也不會~），主要聊下對賬系統(tǒng)如何聯(lián)合 DP 平臺實現(xiàn)完整數(shù)據(jù)對賬方案。

對賬系統(tǒng)概覽

開頭的時序圖，我們可以看到整個對賬過程設計好幾個業(yè)務流程，那在這里對賬系統(tǒng)內部將會維護一個流程狀態(tài)機，當前一個流程處理結束之后，下一個流程才能被觸發(fā)。

由于當前對賬系統(tǒng)實現(xiàn)方案，涉及對賬系統(tǒng)與 DP 平臺，對賬系統(tǒng)目前沒辦法調用 DP 平臺觸發(fā)任務，但是 DP 平臺可以通過通過 HTTP 接口調用對賬系統(tǒng)。

所以當前流程觸發(fā)的方式使用的是定時任務的方案，每個流程有一個單獨的定時任務。

對賬系統(tǒng)內的定時任務觸發(fā)的時候，將會判斷當前流程是否已經(jīng)到達執(zhí)行條件，即判斷一下當前任務的狀態(tài)。

每個定時任務觸發(fā)時間人為設置的時候，岔開一兩分鐘，防止同時運行。

DP 平臺使用自帶調度任務，對賬系統(tǒng)無法控制 DP 任務的運行。

DP 平臺定時任務可以通過運行 Scala 腳本代碼，調用對賬系統(tǒng)提供 HTTP ?查詢接口，通過這種方式判斷當前流程是否已經(jīng)到達執(zhí)行條件。

下面詳細解釋一下每個流程。

初始化對賬任務

對賬系統(tǒng)依靠對賬任務記錄推動流轉，目前每天凌晨將會初始化生成對賬任務記錄，后續(xù)任務流轉就可以從這里開始。

對賬系統(tǒng)維護一張對賬核對規(guī)則表：

對賬核對規(guī)則表關鍵字段含義如下：

• channel_code ?渠道編碼，每個支付渠道將會分配一個唯一渠道編碼，例如微信，支付寶
• biz_type 業(yè)務類型，例如支付，退款，提現(xiàn)等
• status 是否生效

每次對接新的支付渠道，對賬配置規(guī)則需要新增核對規(guī)則。

初始化對賬定時任務將會查找核對規(guī)則表中所有的生效的配置規(guī)則，依次生成當天的對賬任務記錄：

對賬任務記錄部分字段與核對規(guī)則表含義一樣，不再贅述，其他字段含義如下：

• bill_date 賬期，一般 D 日對賬任務核對 D-1 數(shù)據(jù)，所以賬期為 D-1 日
• batch_no 對賬批次，生成規(guī)則如下：賬期+渠道編碼+ 001
• phase,當前對賬任務處于階段，根據(jù)上面對賬流程可以分為
  • 初始化
  • 數(shù)據(jù)收集
  • 存疑處理
  • 數(shù)據(jù)核對
  • 二次存疑處理
  • 數(shù)據(jù)匯總
  • 差錯數(shù)據(jù)推送
• error_reason 錯誤原因

初始化對賬任務結束之后，對賬任務流程推動到第二階段，數(shù)據(jù)收集。

數(shù)據(jù)收集

數(shù)據(jù)收集階段，收集兩端待核對的數(shù)據(jù)，為后面的數(shù)據(jù)核對任務提供核對數(shù)據(jù)。

數(shù)據(jù)收集階段分為兩部分：

• 本端數(shù)據(jù)收集，即自己方產(chǎn)生的支付數(shù)據(jù)
• 對端數(shù)據(jù)收集，即三方渠道產(chǎn)生支付數(shù)據(jù)

本端數(shù)據(jù)收集

本端數(shù)據(jù)，是自己業(yè)務產(chǎn)生的支付數(shù)據(jù)，這些數(shù)據(jù)原本存在各個業(yè)務的數(shù)據(jù)庫中。

對賬系統(tǒng)獲取這些支付數(shù)據(jù)，一般有兩種方式：

• 查詢，對賬系統(tǒng)主動拉取
• 推送，對賬系統(tǒng)監(jiān)聽獲取數(shù)據(jù)

查詢數(shù)據(jù)方式上篇文章也聊到過，數(shù)據(jù)量小的情況下，沒什么問題。一旦數(shù)據(jù)量變大，查詢效率就會變低。

所以這里我們采用推送的方式，對賬系統(tǒng)監(jiān)聽各個業(yè)務數(shù)據(jù)表 binlog，每當業(yè)務數(shù)據(jù)發(fā)生變動，對賬系統(tǒng)就可以接受到 binlog 消息。

對賬系統(tǒng)接受到 binlog 消息，將會判斷當前消息是否需要過濾，是否已經(jīng)支付成功等等，滿足條件之后，binlog 消息將會插入本端數(shù)據(jù)表中，表結構如下：

本端記錄表關鍵字段含義如下：

• channel_code ?渠道編碼，每個支付渠道將會分配一個唯一渠道編碼，例如微信，支付寶
• biz_order_no 本端支付流水號
• bill_date 賬期
• status 狀態(tài)
• is_check 對賬狀態(tài)，0-未核對，1-已核對
• trade_amount 支付金額
• channel_order_no 三方渠道支付單號
• merchant_no 商戶號
• sub_merchant_no 子商戶號

上面展示的支付記錄表結構，根據(jù)業(yè)務類型不同，本端其實還有退款記錄表，提現(xiàn)記錄表等。

這里設計的時候，實際上也可以將所有業(yè)務數(shù)據(jù)放在一張表中，然后根據(jù)業(yè)務類型字段區(qū)分。

對端數(shù)據(jù)收集

對端數(shù)據(jù)，就是第三方支付渠道產(chǎn)生支付數(shù)據(jù)，一般 D 日產(chǎn)生交易之后，D+1 日第三方渠道將會生成一個對賬文件。

對賬系統(tǒng)需要從對端提供的對賬文件獲取對端數(shù)據(jù)。

渠道的對賬文件，下載方式，文件類型存在很大的差異，每次接入新的支付渠道，這里需要經(jīng)過新的開發(fā)。

對端數(shù)據(jù)這里維護了一張渠道下載配置表，對端數(shù)據(jù)收集的時候將會獲取所有可用配置：

渠道下載配置表關鍵字段含義如下：

• mch_id 三方渠道分配的商戶號
• type 下載類型
  • FTP
  • SFTP
  • HTTP
• download_param 下載的配置參數(shù)，比如 ftp 的地址，登錄密碼，下載地址等。

對賬文件下載成功之后，需要根據(jù)文件類型進行解析，最后轉化自己的需要的對賬數(shù)據(jù)入庫。

對端數(shù)據(jù)表結構如下：

上面關鍵字段與本端記錄表類似，額外新增字段:

• channel_fee 渠道手續(xù)費，用于統(tǒng)計渠道收的手續(xù)費

同樣渠道記錄表根據(jù)根據(jù)業(yè)務類型也分為退款渠道記錄表，提現(xiàn)渠道記錄表等，同樣也可以合并成一張表，根據(jù)業(yè)務類型區(qū)分。

對端數(shù)據(jù)收集階段，由于拉取三方渠道的對賬文件，那有時候渠道端存在異常，將會導致對賬文件下載延遲，從而導致其他任務也出現(xiàn)的相應的延遲。

這一點是整個對賬流程中，相對不可控的問題。我們需要在對賬流程設計中考慮這一點。

對賬文件下載解析成功入庫之后，對賬流程將會流轉到下一個流程存疑數(shù)據(jù)處理。

存疑數(shù)據(jù)處理

講解這個流程之前，先給大家解釋一下什么是存疑數(shù)據(jù)？

正常支付過程中，會存在一個兩邊賬期不一致的問題，比如說本端數(shù)據(jù)支付時間是 2021 年 12 月 28 日 23 點 59 分 59 秒，那么本端認為這筆支付交易賬期是 2021 年 12 月 28 日。

然而這筆支付發(fā)送給三方渠道之后，三方渠道支付成功的時間已經(jīng)是 2021 年 12 月 29 日 0 點 0 分 2 秒，三方渠道支付賬期記為2021 年 12 月 29 日。

這種情況下我們這邊記錄賬期是2021 年 12 月 28 日，但是第三方渠道這筆記錄是 2021 年 12 月 29 日，所以 2021 年 12 月 28 日對賬單上沒有這筆支付記錄，這就導致一筆差異數(shù)據(jù)（一端有/一端無）的情況。

上面這種情況就是典型因為日切問題導致差異。

但是我們知道 2021 年 12 月 29 日對賬單上肯定會包含這筆，所以我們可以先把這筆差異數(shù)據(jù)掛起，當做存疑數(shù)據(jù)，等到2021 年 12 月 29 日賬期對賬的時候，對方賬單包含這筆，當天就能核對成功，這就解決這筆差異數(shù)據(jù)。

所以說存疑數(shù)據(jù)，就跟其字面意思一樣，當這筆數(shù)據(jù)當前處理不了的時候，那就現(xiàn)放著，不做定論，過一天我再嘗試處理一下。

除了上面日切問題導致的差異數(shù)據(jù)以外，還有一些情況：

• 網(wǎng)絡問題，導致兩邊訂單狀態(tài)不一致。
• 測試環(huán)境與生產(chǎn)環(huán)境共用一個三方渠道商戶號，測試環(huán)境產(chǎn)生的交易出現(xiàn)在對賬單里

存疑數(shù)據(jù)分為三種類型：

• 本端有，渠道無，即本端存在訂單信息，渠道賬單記錄沒有訂單信息，可能是日切導致的問題
• 渠道有，本端無，即本端不存在訂單信息，渠道端賬單記錄卻有訂單信息，可能是測試環(huán)境與生產(chǎn)環(huán)境共用渠道參數(shù)
• 金額不平，即雙方都存在訂單信息，但是雙方訂單金額不一致

了解完存疑數(shù)據(jù)的定義，我們再來看下存疑數(shù)據(jù)處理的流程。

存疑數(shù)據(jù)將會由下面的流程中產(chǎn)生，這里先來看下存疑表結構：

關鍵字段如下：

• batch_no 批次號
• biz_id 業(yè)務單號
• biz_amount 金額
• status ?0-未處理，1-已處理
• biz_date 賬期
• biz_type 業(yè)務類型
• channel_code 渠道類型
• delayed_times 延遲天數(shù)
• merchant_no 商戶號
• sub_merchant_no 子商戶號
• buffer_type 存疑類型，0-本端存疑，1-渠道存疑

存疑處理過程將會撈起所有存疑表中還未處理的存疑數(shù)據(jù)，根據(jù)存疑類型反向查找對賬數(shù)據(jù)表。例如：

• 渠道存疑（第一天對賬，本端有，渠道無），查找對端數(shù)據(jù)
• 本端存疑（第一天對賬，本端無，渠道有），查找本端數(shù)據(jù)

查找對端/本端數(shù)據(jù)，都是根據(jù)支付流水號加業(yè)務類型查找定位。

如果在本端/對端數(shù)據(jù)中找到，這里還需要再對比一下金額：

• 如果金額不相等，代表單號相同，但是金額不等，將這筆移動到支付差異表
• 如果金額相等，代表這兩筆核平，存疑表將這筆數(shù)據(jù)更新為核對成功，本端/對端數(shù)據(jù)更新為對賬成功

上面這一步比較重要，因為下面對賬核對過程主要核對要素是支付流水號+支付金額，通過這種方式收集單片賬是無法知道是因為單號不存在，還是因為金額不存在原因，具體流程可以看下下面核對流程。

如果在本端/對端數(shù)據(jù)還是找不到,那就根據(jù)渠道配置的存疑規(guī)則，如果當前已經(jīng)存疑的天數(shù)大于配置渠道存疑天數(shù)，則將數(shù)據(jù)直接移動到差錯表。

如果存疑天數(shù)小于當前渠道配置天數(shù)，那就不要管，繼續(xù)保存在存疑表，等待下一天存疑數(shù)據(jù)處理。

一般來說，日切導致的數(shù)據(jù)，存疑一天，就可以解決。但是有些渠道可能是 T+1 在對賬，這種情況需要配置的存疑天數(shù)就要長一點了。

本地存疑數(shù)據(jù)處理結束之后，下面就要開始 DP 數(shù)據(jù)處理。

總結

上篇文章主要聊了對賬流程前半部分，這幾個流程主要是為了后續(xù) DP 平臺核對收集業(yè)務數(shù)據(jù)。

這里存疑流程處理比較關鍵，不熟悉對賬流程的同學，這里需要重點關注下。

下篇文章主要講下 DP 平臺對賬數(shù)據(jù)如何核對，敬請期待。