支付對賬
很早 之前寫過一篇支付對賬相關文章，那時候負責對賬系統日均處理數量比較小。
那最近正在接手現在的對賬系統，由於當前系統日均數量都在千萬級，所以對賬系統架構與之前架構完全不一樣。
那就這個話題，聊聊如何實現千萬級資料支付的對賬系統。
什麼是對賬？
我們先來回顧下什麼是對賬？
也許你對對賬這個概念比較模糊，但是這個場景你肯定碰到過。
上班路上買了一個煎餅，加了根裡脊與王中王，然後你掃了老闆的二維碼付了 10 元錢。
你跟老闆說你已經付了 10 元錢，老闆看了下手機，果然有一條 10 元支付記錄，老闆確認收到錢，然後就把煎餅給你。
這個過程，你說你付了 10 元，老闆確認收到 10 元，這就是一隻簡單的對賬過程。
回到我們支付場景，使用者下單使用微信支付 100 元購買了一個狗頭抱枕，這時我們這邊會生成一條支付記錄，同時微信支付也會生成記錄。
那微信第二天就會生成一個賬單記錄，我們拿到之後把我們的交易記錄跟微信記錄逐筆核對，這就是支付對賬。
為什麼需要對賬？
正常支付的情況下，兩邊（我們/第三方支付渠道）都會產生交易資料，那支付對賬過程，兩邊資料一致，大家各自安好，不用處理什麼。
但是有些異常情況下，可能由於網路問題，導致兩邊資料存在不一致的情況，支付對賬就可以主動發現這些交易。
對賬可以說支付系統最後一道安全防線，通過對賬我們可及時的對之前支付進行糾錯，避免訂單差錯越積越多，最後財務盤點變成一筆糊塗賬。
支付對賬系統
開篇先來一張圖，先來看下整體對賬系統架構圖：
整個對賬系統分為兩個模組
- 對賬模組
- 差錯模組
對賬模組，主要負責對賬檔案拉取，資料解析，資料核對，資料彙總等任務。
差錯模組是對賬模組後置任務，對賬模組核對過程產生無法核對成功的資料，這類資料件將會推送給差錯系統。
差錯系統將會根據規則生成差錯訂單，運營人員可以在後臺處理這列資料。
今天這篇文章先不聊具體的系統設計，先來回顧下之前的對賬系統設計，簡單瞭解下對賬的整體流程。
對賬系統設計
對賬系統如果從流程上來講，其實非常簡單，引用一下之前文章流程圖：
https://studyidea.cn/articles/2019/08/26/1566790305561.html
整體流程可以簡單分為三個模組：
- 本端資料處理
- 對端資料處理
- 本端資料與渠道端資料核對
本端資料指的是我們應用產生的支付記錄，這裡根據賬期（交易日期）與渠道編號獲取單一渠道的所有支付記錄。
對端資料指的是第三方支付渠道支付記錄，一般通過下載對賬檔案獲取。
由於每個渠道下載方式，檔案格式都不太一樣，對端資料處理的時候需要將其轉化統一資料格式，標準化在入庫儲存。
網上找了一份通用賬單，可以參考：
對端資料轉化儲存之後，對賬流程中，對端資料也需要跟本端資料一樣，獲取當前賬期下所有記錄。
兩端資料都獲取成功之後，接下來就是本地資料逐筆核對。
核對流程可以參考之前寫的流程：
上面流程其實也比較簡單，翻譯一下：
查詢本端資料/對端資料，然後轉化儲存到 Map 中，其中 key 為訂單號，value 為本端/對端訂單物件。
然後遍歷本端資料 Map 物件，依次去對端資料 Map查詢。如果能查詢到，說明對端資料也有這筆。這筆核對成功，對端資料集中移除這筆。
如果查詢不到，說明這筆資料為差異資料，它在本端存在，對端不存在 ，將其移動到差異資料集中。
最後，本端資料遍歷結束，如果對端資料集還存在資料，那就證明這些資料也是差異資料，他們在對端存在，本端不存在 ，將其也移動到差異資料集中。
PS:上述流程存在瑕疵，只能核對出兩邊訂單互有缺失的流程 ，但是實際情況下還會碰到兩邊訂單都存在，但是訂單金額卻不一樣的差異資料。這種情況有可能發現在系統 Bug，比如渠道端上送金額單位為元，但是實際上送金額單位為分，這就導致對賬兩端金額不一致。
之前對賬系統日均處理的支付資料峰值在幾十萬，所以上面的流程沒什麼問題，還可以抗住，正常處理。
但是目前的支付資料日均在千萬級，如果還是用這種方式對賬，當前系統可能會直接崩了。。。
千萬資料級帶來的挑戰
第一個，查詢效率。
本端/對端資料通過分頁查詢業務資料表獲取當天所有的資料。隨著每天支付資料累計，業務表中資料將會越來越多，這就會導致資料查詢變慢。
實際過程我們發現，單個渠道資料量很大的情況下，對賬完成需要一兩個小時。
雖然說對賬是一個離線流程，允許對賬完成時間可以久一點。但是對賬流程是後續其他任務的前置流程，整個對賬流程還是需要在中午之前完成，這樣運營同學就可以在下午處理。
第二個問題，OOM。
上面流程中，我們把把全部資料載入到記憶體中，小資料量下沒什麼問題。
但是在千萬級資料情況下，資料都載入到記憶體中，並且還是載入了兩份資料（本端、對端）,這就很容易吃完整個應用記憶體，從而導致 Full GC，甚至還有可能導致應用 OOM。
而且這還會導致級聯反應，一個任務引發 Full GC，導致其他渠道對賬收到影響。
第三個問題，效能問題。
原先系統設計上，單一渠道對賬處理流程只能在單個機器上處理，無法並行處理。
這就導致系統設計伸縮性很差，伺服器資源也被大量的浪費。
千萬資料級對賬解決辦法
上面系統程式碼，實際上還是存在優化空間，可以利用單機多執行緒並行處理，但是大資料下其實帶來效果不是很好。
那主要原因是因為發生在系統架構上，當前系統使用底層使用 MySQL 處理的。
傳統的 MySQL 是 OLTP （on-line transaction processing），這個結構決定它適合用於高併發，小事務 業務資料處理。
但是對賬業務特性動輒就是百萬級，千萬級資料，資料量處理非常大。但是對賬資料處理大多是一次性，不會頻繁更新。
上面業務特性決定了，MySQL 這種 OLTP 系統不太適合大資料級對賬業務。
那專業的事應該交給專業的人去做，對賬業務也一樣，這種大資料級業務比較適合由 Hive、Spark SQL 等 OLAP去做。
總結
今天本篇文章只是一個序曲，主要聊聊對賬業務基本流程，聊聊之前系統架構在大資料下存在的問題。
後面文章再會介紹下大資料下對賬系統如何設計，對賬之後差錯資料如何處理，盡請期待。