以系統里的出金交易為例， 與銀行對賬不外乎做兩件事：①T+1日拉取銀行賬單，保存銀行賬單交易流水；②銀行賬單交易流水與本系統里的通道交易流水比對並記錄差異。 數據表設計 數據表表名comment主要欄位 銀行賬單批次表 bank_bill_batch 銀行賬單表，每銀行每天一條記錄 batchNo- ...
以系統里的出金交易為例， 與銀行對賬不外乎做兩件事：①T+1日拉取銀行賬單，保存銀行賬單交易流水；②銀行賬單交易流水與本系統里的通道交易流水比對並記錄差異。
數據表設計
| 數據表 | 表名 | comment | 主要欄位 |
|---|---|---|---|
| 銀行賬單批次表 | bank_bill_batch | 銀行賬單表，每銀行每天一條記錄 |
batchNo-批次號（PK） bankId-系統里記錄的銀行通道編號 trans_date-交易日期 createTIme-記錄創建時間，即賬單的首次拉取時間 updateTime-最後更新時間 checkState-對賬處理狀態 - IPS（初始待對賬/對賬中/對賬完成） |
| 銀行賬單交易流水 | bank_bill_detail | 銀行賬單交易明細 |
batchNo-批次號（PK） bankId-系統里記錄的銀行通道編號 transOrderNo-系統里的交易單號 bankTransOrderNo-銀行側交易單號 bankTransState-銀行側交易狀態（程式里轉換為系統里的交易狀態） bankTransAmount-交易金額，以分為單位存儲 bankTransTime-銀行側交易完成時間 createTIme-記錄創建時間 |
| 銀行對賬記錄表 | bank_bill_check_result | 銀行賬單與系統交易對賬結果 |
如何實現對賬？
毋庸置疑，實現方案是使用定時任務。如，每隔30分鐘從系統對接的各銀行獲取賬單，再進行對賬。
| 拉取銀行賬單JOB | 銀行對賬JOB |
|---|---|
| ↓ | ↓ |
|
獲取需要拉取賬單的銀行通道列表-bankList 依次遍歷 bankList |
查詢bank_bill_batch，獲取待對賬的賬單批次-batchList 依次遍歷batchList |
| ↓ | ↓ |
|
拉取銀行賬單方法(){ 防重覆執行控制 組裝銀行請求參數，拉取銀行賬單 持久化入庫，包括銀行賬單批次表和賬單明細表（事務） } |
銀行對賬方法(){ 防重覆執行控制 更新batch的checkState=P 對該批次與系統里的T-1日交易進行check 完成後，標記batch的checkState=S |
細節
銀行賬單是在T+1日生成T日賬單。不同銀行的對賬單的具體生成時間點有所不同，有的是01:00，有的可能是09:00，甚至有的是中午11:00。1因此，定時任務的開始時間可以從00:30開始，每隔半小時觸發。銀行賬單一旦拉取完成，後續觸發時不再重覆拉取。
上面表格裡的方案是兩個定時任務，即將拉取銀行賬單與銀行對賬分開了。 這是有缺點的。——可能出現對賬不及時的情況。
那麼，如何優化呢？ 保留一個JOB即可。 拉取銀行賬單的業務完成後，則非同步觸發銀行對賬，保證銀行對賬及時性。
【花絮】
我組起初也是2個定時任務，拉取銀行賬單JOB是整點每隔1小時執行（cron=0 0 1-12/1 * * ?），銀行對賬JOB是整半點點每隔1小時執行（cron=0 30 1-12/1 * * ?）。後來，產品經理和結算人員反饋對賬不及時。開發人員就不斷調整這2個cron表達式，讓其觸發時間間隔更接近。 例如，變更銀行對賬JOB的cron=cron=0 15 1-12/1 * * ?。 但這樣依然無法根本解決對賬不及時的問題。 因此，更合適的實現方案是，拉取到對賬單後就非同步觸發對賬。
【EOF】知識就是力量，但更重要的是...。歡迎關註我的微信公眾號「靠譜的程式員」，解密靠譜程式員的日常，讓我們一起做靠譜的程式員。
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/17891549.html
