>更多支付內容請移步個人站: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...
美的支付 對賬系統實現
對賬,可以發現渠道方與我方交易中的差異。根據差異的不同,再做具體的操作。隨著美的支付接入的渠道增多,日交易量逐漸增大的情況下,人工對賬已經不能滿足財務的要求,系統對賬提上日程 待解決的問題 替代人工對賬,解放人工對賬的工作量,提公升對賬效率,實現系統自動化 對賬差異可自動進行對應處理,輸出對賬結果 ...