閱讀鏈結
支付對賬系統是支付清結算體系中具體基礎性意義的乙個環節，是確保支付平台與各類第三方支付渠道資料一致性的關鍵系統，是商戶資金結算、資金劃撥、資金報表等邏輯準確執行的重要前提。通過閱讀本次內容來了解，支付對賬系統如何在資料不斷增長的情況下演進。
在進行賬單資料儲存時為了提高效率，需要將標準賬單檔案格式設計得與表結構一致，這樣在完成資料轉換後可以直接將檔案load/copy到資料庫中，這樣速度會快很多；而考慮資料規模會增長得超級大，可以儲存在hive中。
對於對賬，相當於兩個資料集的交集，以平台訂單號作為關聯條件，將賬單表中的資料與支付平台訂單表的資料進行full join得到乙個集合全量，得到的集合會是乙個交集、兩個補集。處於交集部分的資料集說明根據訂單號是可以對應上的，還需對訂單金額對比，如果一致則無差錯，對平的資料集按照結算資料要求取賬單資料+平台訂單資料業務字段全集，直接生成對賬明細表，不平則計入對賬差錯資料表。
對於對賬差錯一般分為三類，長款、短款、金額錯誤。根據具體的差錯型別及原因，結合整個支付系統的流程來保證系統間資料的一致性。
對於對賬系統的演變主要需要從考慮資料的增長、任務資源的合理配置以及系統監控這幾個方向去考慮。如果資料量持續增長到傳統方式已無法處理，可以採用spark streming+hive+tidb等組合技術方案進行改進。
此外對賬系統是乙個以定時任務為主的系統，對於定時任務處理框架的選擇可以採用分布式任務框架（推薦elasticjob/saturn）+自定義任務邏輯的方式綜合處理（如有些任務存在先後順序，如果框架本身不提供這類處理功能，則需要通過業務規則限制）。
而從系統監控角度，由於任務系統不同於實時交易流程，具有執行時間長、資料操作範圍廣泛的特點，除了進行正常的程序級別的監控外，對於各個任務的執**況，也需要進行比較細緻的監控，這部分可以通過監控打點等方式綜合解決；而對於業務異常日誌的監控則可以通過sentry等日誌監控工具進行監控。
《架構漫談》閱讀筆記
在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的 當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的 一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的...
《架構漫談》閱讀筆記
架構漫談是由資深架構師王概凱執筆的系列專欄，通過對其閱讀，我從中逐步認識到了什麼是架構，怎樣做好架構，軟體架構如何落地等內容。一 什麼是架構 在軟體行業，對於什麼是架構一直有很多的爭論。事實上，架構在軟體發明時的n多年以前，就已經存在了，這個詞最早出現在建築上。架構產生的五個動力可以概括為 由個人執...
《架構漫談》閱讀筆記
軟體架構師如何工作？不同於軟體工程中只需要編碼的 低階 碼農，一名合格的軟體架構師首先要對架構有深刻的理解。那麼什麼是架構？從建築的角度解釋，架構是計畫 設計和建造建築物 物理結構的過程和生產活動。從這個定義上看，架構像乙個過程，但又不明確。為了弄清這個問題，我們首先要了解為什麼會產生架構？在最早期...