>更多支付內容請移步個人站：ykblog.top
從整體來看，按照時序維度的先後，系統對賬主要分為三階段的工作。分別是資料準備、資料核對和差錯處理。資料準備細分一下，又分為檔案獲取、檔案解析、資料清洗。
在對賬專業概念中，資料核對和差錯處理又叫軋賬和平賬。
具體設計腦圖如下:
對賬各個模組設計
資料準備
資料準備，顧名思義，我們需要把對賬所需的全部資料，接入到我們的對賬系統。該模組主要實現兩個目標：為不同的外部系統提供多元化的接入機制。
通過資料適配的手段把外部資料以統一的格式進行轉換和儲存。
在資料接入層，我們會針對不同的資料接入方提供三種不同的資料接入模式。如下圖：
資料拉取
主動拉取資料，並通過資料適配的方式，將資料儲存到對賬資料池中。
資料推送
指定標準規範和格式，供各個接入方使用，統一格式推送到對賬服務。
人工上傳
提供標準的檔案模板，由業務接入方填充資料，通過後台檔案上傳或sftp上傳工具的方式將資料上傳到對賬服務。
解壓檔案
解析檔案
儲存資料
將第三步得到的資料儲存、持久化到資料庫，一般底稿資料都儲存最全數方便問題追溯。
資料清洗顧名思義，即對準備的上下游資料進行清洗。
清洗的作用或原因：
從底稿提取對賬核心字段
一般參與對賬的字段就幾個，具體字段：銀行卡號、銀行單號、業務單號、支付金額、支付方式、支付完成時間、核對狀態。
上文提到底稿一般建議儲存所有資料，資料太多影響對賬效能和效率。
合併、排除無用資料
上文提到底稿一般建議儲存所有資料，難免有無用資料需要剔除，或者排除業務或財務指定無需對賬的資料；合併特殊業務或流程產生的n對1資料。
資料核對
對賬的核心
資料核對是對賬的核心，對賬的主邏輯；一般對賬方式有兩種，即對明細賬和對總賬，對總賬一般包括總金額和總條目。一般做法為對明細賬，即上下游每條記錄逐一比對。
核對的結果
核對一般就是兩個結果：對上帳和對不上賬，對不上賬有分三種結果，上游單邊(支付中一般稱為企業單邊，即長款)，下游單邊(支付中一般稱為銀行邊，即漏單)，金額不等(即兩邊都有資料，金額對不上)。
設計normal和different兩張表，分別儲存不同的核對結果資料，方便後期統計以及為業務提供能力。
具體對賬的方法有多種，比如：sql核對
exist insert select
最簡單的方式，也是問題比較多方式，對資料庫壓力比較大，資料特別多的時候，對賬效率比較低。
redis核對
set集合分別diff (inter)上游、下游資料
比較好的方式，可以降低資料庫壓力，redis方便根據資料量做水平擴充套件。
sprak核對
採用流式運算進行比對；(具體做法待擴充套件)
差錯處理
在一般系統中，差錯處理分為兩種，一種人工來處理，一種系統自動來處理。
系統自動處理一般為：自動補單和驅動下游流程完成兩種方式。主要有如下情況：
下游單邊(銀行單邊)情況
業務未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的非同步通知導致。
一般處理是將本地狀態修改為已支付，並做響應的後續處理，比如通知業務方等。
上游單邊(企業單邊)情況
業務已支付，但是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。
在排除跨日因素外，這種情況非常少見，需要了解具體原因後做處理。
金額不等情況
業務已支付，支付渠道已支付，但是金額不同，這個需要人工核查。
對賬統計
根據對賬處理結果，統計的資料由：彙總總條目、彙總總金額、彙總差異結果、彙總單邊結果、彙總處理結果。
對賬系統相關設計
分布式定時系統
一般對賬系統都是n+1離線對賬，所有上述所有模組的設計一般使用定時任務去執行。不可能所有模組、所有銀行卡都用乙個任務去執行，也不可能只用一台機器去執行，這樣一天可能都跑不完所有的資料。
所以考慮到優化，一般設定為集群分布式的去跑任務，所以涉及乙個分布式定時系統對對賬系統來說很重要，考慮成本和時間問題，可以簡單實現分布式任務效果。分布式定時系統的設計後續再單獨**。
即使所有任務都按模組化去進行劃分，按模組化單獨起任務去執行業務邏輯，也會存在時間效率的瓶頸(因為下文提到的依賴關係，導致並不能讓所有的任務都並行起來)。再加上銀行卡號比較多的情況下，最好情況就是各個銀行卡號並行處理，即併發粒度設計到銀行卡號維度，使用多執行緒把所有銀行卡的對賬任務並行起來。
依賴鏈設計
所有模組是存在依賴關係的，比如清洗之前，肯定要資料準備完成；但是上游資料和下游資料的準備、清洗可以併發的執行。整體依賴鏈如下：
核心對賬優化
sprak 實現
具體實現過程會在後續博文中詳細介紹。
對賬系統資料庫模型
按以上設計模型，具體資料模型如下介紹。
底稿資料表各個上游資料、下游資料抓取、解析的底稿資料 。
不只兩張表，由具體業務決定；資料量比較大，一般按日期水平分表，按實際業務考慮要不要垂直分表。
清洗表從各個上游資料、下游資料的底稿資料取部分字段。
不只兩張表，由具體業務決定；資料量比較大，一般按日期分表。
對賬結果表正常表
用來存放對上賬的資料(即對賬結果正常的資料，一般資料量比較大，需要按日期分表)
異常表用來存放對不上賬的資料(上游單邊、下游單邊、金額不等)。
對賬彙總表
即對對賬資料的彙總
技術相關表
定時配置、賬戶配置、異常資訊等等相關表
支付系統對賬設計
對賬系統作為支付系統中的基石系統,處於整個支付環節中的最後一層，主要用來保證我方支付資料與第三方支付渠道或銀行的資料一致性。在沒有對賬系統之前，財務在第二日手工核對前一日的應收與實收。倘若不一致，這就需要一一核對資料，找出不一致的資料。對賬系統出現之後，就可減少以這種繁瑣手工操作，財務只需要每天關注...
對賬系統框架
首頁導航選單 14 首頁,京東,拍拍,噹噹,優購,qq網購,亞馬遜,1號店,vjia,好樂買,b2c,系統,收藏 功能選單 102 01.駱駝服飾 a.原始資料 賬目統計 table srje,zcje srje common 收入金額 zcje common 支出金額 匯入資料 table sho...
美的支付 對賬系統實現
對賬，可以發現渠道方與我方交易中的差異。根據差異的不同，再做具體的操作。隨著美的支付接入的渠道增多，日交易量逐漸增大的情況下，人工對賬已經不能滿足財務的要求，系統對賬提上日程 待解決的問題 替代人工對賬，解放人工對賬的工作量，提公升對賬效率，實現系統自動化 對賬差異可自動進行對應處理，輸出對賬結果 ...