大家好，我是老三，好久不見，最近比較忙碌，狀态也不是太好，很久沒有輸出。
最近在做對賬系統的調研和設計，給大家分享一些對賬系統的知識。
什麼是對賬？
有個男人叫小帥，娶了個老婆，叫小美，早上，小美給小帥二十塊錢買早餐，小帥買了包子、油條、豆漿回來，并說錢已經花完了，小美不信，拉着小帥到了早餐鋪，拉着老闆的賬單對了一下，發現還剩兩塊錢……
這就是一個簡單的對賬場景，我們再看看電商的大概支付鍊路：
- 使用者在電商平台下單，支付
- 支付服務向外部支付管道發起支付請求
- 支付管道扣減使用者餘額，或者請求銀行扣款
- 完成支付後，支付服務同步支付狀态，電商平台開始履約（發貨）
- 到這就完了嗎？還沒有，支付管道還要做清結算，把交易的餘額結算到商戶賬戶
可以看到，涉及到的系統還是比較多的，對電商内部而言，可能涉及到支付、訂單、風控、履約，對于外部而言，電商和第三方管道，支付管道和銀行。内部部之間，想不出差錯那簡直得圖靈、馮諾依曼諸神保佑，是以，對賬系統，是交易最後也是非常重要的一環，
通過對賬，能找到各個内、外部系統之間不一緻的交易，并通過差錯處理，厘清賬務，防止資損。
如何對賬？
電商系統内部的對賬相對簡單一些，不管是通接口、還是資料聚合，都可以跨服務、跨庫地核對交易資料。
我們這裡主要讨論電商平台和三方管道的對賬：
對的是哪些賬？
對于電商公司而言：
- 面對使用者，希望“不少收一分錢，不多收一分錢”，和使用者之間能做到錢貨兩清，這就要求電商平台的應收應付和三方管道的實收實付一緻，也就是
業務對賬
- 面對三方管道，希望能做到清算的一緻性，也就實收扣除服務費的金額一緻，還有結算的一緻性，也就是三方管道到商戶賬戶結算金額一緻，也就是
資金對賬
這篇文章我們主要讨論業務對賬。
通過什麼對賬？
通過什麼對賬呢？
對于電商平台内部，需要把各個服務的交易相關資料聚合起來，一般是通過拉的方式：
- binlog訂閱
- 訂閱消息
- 定時任務
對于外部的對賬資料，各個支付管道一般會提供對賬單，不同管道的對賬單格式上不太一樣：
- 微信對賬單，txt格式
- 支付寶對賬單，csv格式
- Paypal對賬單，csv格式
對賬檔案當然是不能直接使用的，需要把三方管道的對賬單，清洗成對賬系統用到的資料：
那對賬檔案是如何擷取的呢？一般主要有兩種方式：
- http接口下載下傳
- ftp伺服器下載下傳
那對賬檔案是什麼時間生成的呢？國内的支付管道一般對賬單生成時間是T+1。
對賬的時機？
什麼時候開始對賬？對賬一般分為兩種：
離線對賬
和
實時對賬
。
我們這篇文章主要講的就是離線對賬，在對賬單下載下傳解析完成之後，開始對賬，也就是所謂的T+1。例如支付寶，6點生成對賬單，可以定時6:30去下載下傳和解析對賬單，解析落庫之後，就可以開始進行對賬。
實時對賬呢，一般是對交易的狀态進行監聽（mq、binlog），監聽到狀态的變化，就開始核對。
對賬邏輯是什麼樣的？
看看離線對賬的邏輯：
那麼對賬是以什麼為基準呢？是本系統的訂單，還是支付管道的訂單？
為了盡可能保證準确性，一般是雙向的，也就是基于本系統訂單，比較三方對賬單，也基于三方對賬單比較本系統對賬單，進行複核。
通常要核對的是這幾個點：
- 支付記錄是否在兩邊都存在
- 支付記錄狀态是否一緻
- 支付記錄的金額是否一緻
如果沒有問題，那這比流水就對平了，反之就是發生了差錯：
- 錯帳：支付狀态不一緻；支付金額不一緻
- 短款：電商平台有支付資訊，支付管道沒有
- 長款：僅支付管道有支付資訊
怎麼處理差錯？
對于常見的有規律的差錯單，我們可以設計一些規則來自動處理，比如跨日交易問題，可以檢視前一日的交易記錄，或者後一日的交易記錄，檢視是否能夠對平。還有其它的一些匯率換算等等問題，都可以嘗試對平。
對于對不平的賬，就需要标記錯帳，進行人工處理，例如發生了掉單，可以給使用者退款；例如使用者未退款，可以嘗試攔截發貨。
支付對賬架構如何設計？
我們來看看一些對賬系統的架構設計：
- 美團
- 有贊對賬架構設計
- 阿裡商旅對賬架構
- 小黑十一點半大佬畫的對賬架構設計
可以看到，主要就是那些東西，資料存儲（DB、緩存、大資料）、資料訂閱（binlog、mq、rpc）、task等等。
小結
這篇文章給大家分享了一些對賬系統的知識，老三對于對賬系統，目前也隻是調研和設計階段，大家有什麼意見可以和我交流，後續會給大家分享更多電商、支付相關的東西，點贊、關注不迷路！
對賬參考和學習資料：
[1].《支付架構實戰》
[2].支付對賬三部曲之資金對賬系統設計篇
[3].支付對賬系統怎麼設計？
[4].支付對賬系統序章：千萬級資料對賬怎麼這麼難？
[5].對賬系統從入門到精通
[6].千萬級支付對賬系統怎麼玩（下篇）？
[7].[美團配送資金安全治理之對賬體系建設