更多支付內(nèi)容請移步個人站：YKBLog.top
對賬整體設(shè)計
從整體來看，按照時序維度的先后，系統(tǒng)對賬主要分為三階段的工作。分別是數(shù)據(jù)準(zhǔn)備、數(shù)據(jù)核對和差錯處理。
- 數(shù)據(jù)準(zhǔn)備細(xì)分一下，又分為文件獲取、文件解析、數(shù)據(jù)清洗。
在對賬專業(yè)概念中，數(shù)據(jù)核對和差錯處理又叫軋賬和平賬。
具體設(shè)計腦圖如下:
對賬各個模塊設(shè)計
數(shù)據(jù)準(zhǔn)備
數(shù)據(jù)準(zhǔn)備，顧名思義，我們需要把對賬所需的全部數(shù)據(jù)，接入到我們的對賬系統(tǒng)。
該模塊主要實現(xiàn)兩個目標(biāo)：
- 為不同的外部系統(tǒng)提供多元化的接入機制。
- 通過數(shù)據(jù)適配的手段把外部數(shù)據(jù)以統(tǒng)一的格式進(jìn)行轉(zhuǎn)換和存儲。
在數(shù)據(jù)接入層，我們會針對不同的數(shù)據(jù)接入方提供三種不同的數(shù)據(jù)接入模式。如下圖：
數(shù)據(jù)拉取
主動拉取數(shù)據(jù)，并通過數(shù)據(jù)適配的方式，將數(shù)據(jù)存儲到對賬數(shù)據(jù)池中。
數(shù)據(jù)推送
指定標(biāo)準(zhǔn)規(guī)范和格式，供各個接入方使用，統(tǒng)一格式推送到對賬服務(wù)。
人工上傳
提供標(biāo)準(zhǔn)的文件模板，由業(yè)務(wù)接入方填充數(shù)據(jù)，通過后臺文件上傳或SFTP上傳工具的方式將數(shù)據(jù)上傳到對賬服務(wù)。
人工上傳文件處理方式步驟如下：
- 下載文件
從指定SFTP服務(wù)器下載文件。 - 解壓文件
一般為zip壓縮包，節(jié)省存儲空間，提高上傳和下載速度。 - 解析文件
一般文件格式為EXCEL（財務(wù)人工上傳文件，一般從銀行或第三方支付后臺下載）、CSV（數(shù)據(jù)接入方一般從數(shù)據(jù)庫導(dǎo)出格式，或第三方支付提供的文件格式）、TXT。 - 存儲數(shù)據(jù)
將第三步得到的數(shù)據(jù)存儲、持久化到數(shù)據(jù)庫，一般底稿數(shù)據(jù)都存儲最全數(shù)方便問題追溯。
數(shù)據(jù)清洗
顧名思義，即對準(zhǔn)備的上下游數(shù)據(jù)進(jìn)行清洗。
清洗的作用或原因：
從底稿提取對賬核心字段
一般參與對賬的字段就幾個，具體字段：銀行卡號、銀行單號、業(yè)務(wù)單號、支付金額、支付方式、支付完成時間、核對狀態(tài)。
上文提到底稿一般建議存儲所有數(shù)據(jù)，數(shù)據(jù)太多影響對賬性能和效率。
合并、排除無用數(shù)據(jù)
上文提到底稿一般建議存儲所有數(shù)據(jù)，難免有無用數(shù)據(jù)需要剔除，或者排除業(yè)務(wù)或財務(wù)指定無需對賬的數(shù)據(jù)；合并特殊業(yè)務(wù)或流程產(chǎn)生的N對1數(shù)據(jù)。
數(shù)據(jù)核對
對賬的核心
數(shù)據(jù)核對是對賬的核心，對賬的主邏輯；一般對賬方式有兩種，即對明細(xì)賬和對總賬，對總賬一般包括總金額和總條目。一般做法為對明細(xì)賬，即上下游每條記錄逐一比對。
核對的結(jié)果
核對一般就是兩個結(jié)果：對上帳和對不上賬，對不上賬有分三種結(jié)果，上游單邊（支付中一般稱為企業(yè)單邊，即長款），下游單邊（支付中一般稱為銀行邊，即漏單），金額不等（即兩邊都有數(shù)據(jù)，金額對不上）。
設(shè)計normal和different兩張表，分別存儲不同的核對結(jié)果數(shù)據(jù)，方便后期統(tǒng)計以及為業(yè)務(wù)提供能力。
具體對賬的方法有多種，比如：
- sql核對
exist insert select
最簡單的方式，也是問題比較多方式，對數(shù)據(jù)庫壓力比較大，數(shù)據(jù)特別多的時候，對賬效率比較低。 - redis核對
set集合分別diff （inter）上游、下游數(shù)據(jù)
比較好的方式，可以降低數(shù)據(jù)庫壓力，redis方便根據(jù)數(shù)據(jù)量做水平擴展。 - sprak核對
采用流式運算進(jìn)行比對；（具體做法待擴展）
差錯處理
在一般系統(tǒng)中，差錯處理分為兩種，一種人工來處理，一種系統(tǒng)自動來處理。
人工處理一般兩個操作：平賬和勾兌，勾兌一般處理的是單邊情況，比如由于系統(tǒng)bug出現(xiàn)的單邊問題，經(jīng)由人工溯源修復(fù)bug之后，相關(guān)業(yè)務(wù)人員即可在對賬后臺將該條數(shù)據(jù)進(jìn)行勾兌。
系統(tǒng)自動處理一般為：自動補單和驅(qū)動下游流程完成兩種方式。主要有如下情況：
下游單邊（銀行單邊）情況
業(yè)務(wù)未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發(fā)的異步通知導(dǎo)致。
一般處理是將本地狀態(tài)修改為已支付，并做響應(yīng)的后續(xù)處理，比如通知業(yè)務(wù)方等。
上游單邊（企業(yè)單邊）情況
業(yè)務(wù)已支付，但是支付渠道中無記錄；或者本地?zé)o記錄，支付渠道有記錄。
在排除跨日因素外，這種情況非常少見，需要了解具體原因后做處理。
金額不等情況
業(yè)務(wù)已支付，支付渠道已支付，但是金額不同，這個需要人工核查。
對賬統(tǒng)計
根據(jù)對賬處理結(jié)果，統(tǒng)計的數(shù)據(jù)由：匯總總條目、匯總總金額、匯總差異結(jié)果、匯總單邊結(jié)果、匯總處理結(jié)果。
業(yè)務(wù)和財務(wù)關(guān)系的統(tǒng)計的相關(guān)信息有：對賬完成時間、對賬是否成功、平賬的金額和訂單數(shù)、差錯的金額和訂單數(shù)、緩存池金額和訂單數(shù)等。
對賬系統(tǒng)相關(guān)設(shè)計
分布式定時系統(tǒng)
一般對賬系統(tǒng)都是N+1離線對賬，所有上述所有模塊的設(shè)計一般使用定時任務(wù)去執(zhí)行。不可能所有模塊、所有銀行卡都用一個任務(wù)去執(zhí)行，也不可能只用一臺機器去執(zhí)行，這樣一天可能都跑不完所有的數(shù)據(jù)。
所以考慮到優(yōu)化，一般設(shè)置為集群分布式的去跑任務(wù)，所以涉及一個分布式定時系統(tǒng)對對賬系統(tǒng)來說很重要，考慮成本和時間問題，可以簡單實現(xiàn)分布式任務(wù)效果。分布式定時系統(tǒng)的設(shè)計后續(xù)再單獨探討。
即使所有任務(wù)都按模塊化去進(jìn)行劃分，按模塊化單獨起任務(wù)去執(zhí)行業(yè)務(wù)邏輯，也會存在時間效率的瓶頸（因為下文提到的依賴關(guān)系，導(dǎo)致并不能讓所有的任務(wù)都并行起來）。再加上銀行卡號比較多的情況下，最好情況就是各個銀行卡號并行處理，即并發(fā)粒度設(shè)計到銀行卡號維度，使用多線程把所有銀行卡的對賬任務(wù)并行起來。
依賴鏈設(shè)計
所有模塊是存在依賴關(guān)系的，比如清洗之前，肯定要數(shù)據(jù)準(zhǔn)備完成；但是上游數(shù)據(jù)和下游數(shù)據(jù)的準(zhǔn)備、清洗可以并發(fā)的執(zhí)行。整體依賴鏈如下：
核心對賬優(yōu)化
上文模塊設(shè)計有提到核心對賬的多種實現(xiàn)思路，這里推薦的兩種：
- redis 實現(xiàn)
- sprak 實現(xiàn)
具體實現(xiàn)過程會在后續(xù)博文中詳細(xì)介紹。
對賬系統(tǒng)數(shù)據(jù)庫模型
按以上設(shè)計模型，具體數(shù)據(jù)模型如下介紹。
底稿數(shù)據(jù)表
- 各個上游數(shù)據(jù)、下游數(shù)據(jù)抓取、解析的底稿數(shù)據(jù) 。
- 不只兩張表，由具體業(yè)務(wù)決定；數(shù)據(jù)量比較大，一般按日期水平分表，按實際業(yè)務(wù)考慮要不要垂直分表。
清洗表
- 從各個上游數(shù)據(jù)、下游數(shù)據(jù)的底稿數(shù)據(jù)取部分字段。
- 不只兩張表，由具體業(yè)務(wù)決定；數(shù)據(jù)量比較大，一般按日期分表。
對賬結(jié)果表
- 正常表
用來存放對上賬的數(shù)據(jù)(即對賬結(jié)果正常的數(shù)據(jù)，一般數(shù)據(jù)量比較大，需要按日期分表) - 異常表
用來存放對不上賬的數(shù)據(jù)（上游單邊、下游單邊、金額不等）。
對賬匯總表
即對對賬數(shù)據(jù)的匯總
技術(shù)相關(guān)表
定時配置、賬戶配置、異常信息等等相關(guān)表
更多支付內(nèi)容請移步個人站：YKBLog.top
