導讀：百度交易中臺作為集團移動生態(tài)戰(zhàn)略的基礎設施，面向收銀交易與清分結算場景，為賦能業(yè)務提供高效交易生態(tài)搭建。目前支持百度體系內多個產(chǎn)品線，主要包含：小程序，地圖打車，百家號，招財貓，好看視頻等。本文主要介紹了百度交易中臺的商戶財務對賬相關的帳房系統(tǒng)，主要從業(yè)務模型以及系統(tǒng)設計來介紹該系統(tǒng)。

全文5184字，預計閱讀時間14分鐘

一、系統(tǒng)介紹

帳房系統(tǒng)是建立在百度交易系統(tǒng)[1]下，收攏聚合了商家/平臺/宿主等接入方的收入/支出流水的對賬系統(tǒng)。商家通過該系統(tǒng)可直接看到自己的收入/其他款項/支出等流水信息，實現(xiàn)按天/月/年的財務對賬。

二、業(yè)務場景

針對不同業(yè)務背景，交易清結算系統(tǒng)產(chǎn)生了不同的流水類型。目前主流的業(yè)務場景包含：1.直播帶貨等場景下的流量主帶貨[2]。2.小程序宿主內的宿主帶貨。3.地圖打車等業(yè)務場景下的平臺分帳。

圖（2-1） 交易中臺業(yè)務背景

這些業(yè)務場景下，交易流水產(chǎn)生的過程如圖（2-2）所示。一個訂單經(jīng)過支付、支付通知（購物車拆子訂單）、訂單維度結算、結算流水推送商家資金池，最后資金池流水才會到帳房系統(tǒng)，交易流水產(chǎn)生在圖（2-2）中的商家訂單結算過程中，一個訂單會產(chǎn)出多條交易流水，推送到下游資金池系統(tǒng)進行商家賬戶記賬，同時產(chǎn)生了對應的資金池流水，帳房系統(tǒng)的數(shù)據(jù)來源就是資金池的流水記錄。目前商家結算產(chǎn)出流水類型有以下幾種：

圖（2-2） 交易流水產(chǎn)生流程

分帳流水（貨款）：對于入駐交易的平臺方，平臺方為商家提供了平臺上的功能，平臺方期望從商家售賣的貨款中收取一定的傭金，作為平臺的收入。基于這種業(yè)務場景，產(chǎn)生了平臺的分帳流水。對應圖（2-2）商家結算中的分帳方式產(chǎn)出，分帳方式包含：按照固定比例，按照固定金額，自主比例分帳以及多方分帳，接入方根據(jù)實際的業(yè)務場景選擇對應的分帳方式。

技術服務費：技術服務費為交易中臺（網(wǎng)訊主體）對使用收銀臺支付的商家，會收取一定比例的錢作為技術服務費，因此產(chǎn)生了對應的技術服務費流水，對應圖（2-2）商家結算中的分帳方式的傭金模式產(chǎn)出，傭金模式包含：固定比例、固定金額以及按照渠道收取。對應商家的其他款項數(shù)據(jù)。

小程序帶貨流水：小程序帶貨流水為流量主收取的帶貨傭金，流量主為商家通過文章、視頻、直播帶貨后，賣出的貨款會分一部分給帶貨的流量主，從而產(chǎn)生了小程序帶貨流水。與分帳流水不同的時，分帳的流水是給入駐的平臺，而帶貨流水最后的結算對象是個人。

宿主帶貨流水：業(yè)務背景是智能小程序開源聯(lián)盟，為宿主和小程序共建生態(tài)。宿主為小程序提供分發(fā)流量及展現(xiàn)入口，有效提升小程序的使用時長及頻次，基于此，宿主產(chǎn)生對在其APP上發(fā)生的交易進行抽傭的訴求，從而實現(xiàn)宿主新商業(yè)變現(xiàn)模式拓展，帶動宿主商業(yè)收入增長。?宿主帶貨流水的產(chǎn)生方式與小程序帶貨類似，區(qū)別是宿主在交易進行和入駐，屬于企業(yè)/公司類型。一個商家屬于一個平臺，也可以和宿主進行綁定，與二者同時進行分賬。

打款流水：打款流水為給商家銀行卡打款的流水。

調整款流水：指打款銀行退匯的流水。

帳房系統(tǒng)將以上的流水劃分為3個類別：收入、支出以及其他款項。

• 收入：指分帳流水

• 其他款項：包含交易中臺收取的技術服務費、打款退回的流水、小程序帶貨流水以及宿主帶貨流水

• 支出：指打款流水

商家整體財務數(shù)據(jù)核對收支平衡的公式為：?

總體對賬公式：商家余額 = 收入 + 其他款項 - 支出

若公式成立則收支流水數(shù)據(jù)準確無誤。若商家想要核對賬期內的財務數(shù)據(jù)，則需要看兩個賬期之間的收入和支出是否一致。例如商家每隔7日進行一次打款（即是支出），則商家只需要核對這7天內的流水數(shù)據(jù)是否滿足以下公式即可。

結算賬期對賬公式：收入 + 其他款項 - 支出= 0

例子說明

交易中臺所支持的業(yè)務場景中，一個訂單會產(chǎn)生多條流水，每一條流水的結算對象也不一樣，因此，這里舉例簡單說明流水屬于的對象。

例子：針對小程序帶貨的場景，一個訂單金額為100元，帶貨流量主分傭10%，平臺分帳5%，交易中臺收取6‰技術服務費。因此各個對象的流水金額如下：

從表中可以看出最后的總金額只有84.4+10+5=99.4元，缺少的0.6元就是交易中臺收取的技術服務費。技術服務費的收取是通過從商家口扣除0.6元實現(xiàn)的，而不是產(chǎn)生0.6元的流水給交易中臺。如果打款周期到了，對應給結算對象的打款金額就分別為84.4元，10元和5元，這樣收入和支出就一致了。

三、系統(tǒng)構架

圖（3-1） 帳房系統(tǒng)架構圖

帳房的整體架構如圖3-1所示，帳房的數(shù)據(jù)來源為上游的資金池流水數(shù)據(jù)，canal監(jiān)聽binlog，解析binlog日志將流水數(shù)據(jù)發(fā)布到bigpipe，帳房系統(tǒng)通過監(jiān)聽bigpipe數(shù)據(jù)，拿到流水數(shù)據(jù)后通過akka完成數(shù)據(jù)的校驗、補充，得到一條完備的流水數(shù)據(jù)。最后通過esClient將流水數(shù)據(jù)寫入百度云es，業(yè)務的查詢以及導出功能都是基于百度云es的數(shù)據(jù)來完成的。與此同時，交易中臺也建立了離線計算系統(tǒng)，通過spark拉取es的集群數(shù)據(jù)，存儲在AFS上，基于此完成離線數(shù)據(jù)統(tǒng)計的功能。?帳房系統(tǒng)以資金池流水數(shù)據(jù)為主，根據(jù)流水類型的不同，補充了來自其他不同系統(tǒng)的數(shù)據(jù)，豐富該條流水的信息，來滿足業(yè)務側查詢的需求，補充的數(shù)據(jù)存儲在es以及數(shù)據(jù)庫中，針對熱點的數(shù)據(jù)，系統(tǒng)使用LoadingCache本地緩存的方式提升處理速度。系統(tǒng)對外輸出數(shù)據(jù)的方式有：第三方API、電商開放平臺、財務運營平臺、業(yè)務商家后臺以及AMIS發(fā)票系統(tǒng)。

四、系統(tǒng)功能拆解

4.1 基于canal的數(shù)據(jù)同步

帳房系統(tǒng)的數(shù)據(jù)來源為上游賬戶資金池系統(tǒng)的流水數(shù)據(jù)，資金池流水數(shù)據(jù)存儲在ddbs數(shù)據(jù)庫中。帳房需要實現(xiàn)準實時數(shù)據(jù)的獲取，同時避免代碼的侵入，因此采用了基于cacal監(jiān)聽ddbs數(shù)據(jù)庫binlog日志的方式，進行數(shù)據(jù)的同步；由于每日的流水產(chǎn)生存在流量高峰，直接將數(shù)據(jù)請求下游帳房系統(tǒng)，可能會對帳房系統(tǒng)產(chǎn)生沖擊，引起系統(tǒng)異常的問題。為了避免這種情況的出現(xiàn)，我們引入了中間件消息隊列（bigpipe）進行流量削峰填谷處理，canal將解析的庫表變更數(shù)據(jù)發(fā)送到消息隊列中，帳房系統(tǒng)采用監(jiān)聽者模式從消息隊列中獲取對應的數(shù)據(jù)，通過java的akka方式進行并發(fā)的數(shù)據(jù)處理。帳房系統(tǒng)通過異步消息以及akka并發(fā)的方式完成數(shù)據(jù)的異步化同步，解決流量高峰問題，實現(xiàn)了數(shù)據(jù)的準實時同步，當前系統(tǒng)的數(shù)據(jù)同步延時控制在秒級別。

4.2 Elasticsearch數(shù)據(jù)存儲

帳房系統(tǒng)業(yè)務需求為商家/用戶對賬需求，主要是為了滿足商家/用戶對于財務相關的對賬數(shù)據(jù)的查詢以及導出。基于這樣的特點，需要查詢大量的數(shù)據(jù)，同時需要完成各個維度的數(shù)據(jù)聚合，而且商家的流水數(shù)據(jù)量遠大于訂單的數(shù)據(jù)量，一個訂單將會產(chǎn)生2-6條的流水。交易訂單中心以及上游賬戶資金池系統(tǒng)的存儲都是采用數(shù)據(jù)庫分度分表的方式進行的，這樣的方式并不適用于帳房系統(tǒng)，引入分表的方式會導致數(shù)據(jù)不均勻的情況產(chǎn)生，對于熱點賬戶的問題難以解決，同時難以完成多維度的數(shù)據(jù)查詢。基于此系統(tǒng)采用了es的存儲方式，通過es支持對外的多維度、準實時的數(shù)據(jù)查詢。

帳房系統(tǒng)早期的數(shù)據(jù)寫入時自定義了routing，使用商家id作為routing，隨著業(yè)務發(fā)展，熱點商戶的數(shù)據(jù)量不斷增加，從而導致es分片出現(xiàn)了數(shù)據(jù)傾斜的情況，進而會引發(fā)es聚合查詢偶發(fā)超時以及偶現(xiàn)寫入失敗的情況。因此系統(tǒng)進行了es數(shù)據(jù)遷移，從而解決數(shù)據(jù)傾斜的問題。同時Elasticsearch 使用一種稱為倒排索引的結構，它適用于快速的全文搜索，因此es對于字段的變更修改無法直接在原來的索引上進行，都是重建索引，進行數(shù)據(jù)的遷移完成的。es數(shù)據(jù)的遷移方式有很多（BOS快照遷移、Logstash、通過Spark遷移數(shù)據(jù)、HDFS快照遷移等），鑒于交易側es數(shù)據(jù)量以及遷移的場景，使用了Logstash同步的方式進行了數(shù)據(jù)的遷移，遷移過程中將文檔的routing設置去除，解決了數(shù)據(jù)傾斜的數(shù)據(jù)。

4.3 數(shù)據(jù)一致性保障

帳房系統(tǒng)其主要功能為商家的對賬，因此商家的流水數(shù)據(jù)的缺失必然會導致商家財務數(shù)據(jù)的錯誤，給商家?guī)韺~上的問題。因此保障帳房的數(shù)據(jù)與上游系統(tǒng)一致，是該系統(tǒng)重要且必須的能力。數(shù)據(jù)一致性的保障，帳房系統(tǒng)通過接入交易平臺的一致性服務系統(tǒng)完成，其流程如圖4-1所示。

圖（4-1） 數(shù)據(jù)一致性保障流程圖

一致性服務通過接收來自上游canal發(fā)送的bp消息，以及帳房系統(tǒng)寫入es成功后發(fā)送的bp消息，將二者的消息存儲至mysql數(shù)據(jù)庫中，每日定時對上下游系統(tǒng)的數(shù)據(jù)進行對比分析，得出對應的差異數(shù)據(jù)，然后通過調用對應的修復接口完成數(shù)據(jù)的修復。一致性服務留存了7日內的消息數(shù)據(jù)，過期定時清理，保證服務的數(shù)據(jù)量不會過大，不影響數(shù)據(jù)庫性能。除了一致性服務的保障之外，每月會通過spark進行離線數(shù)據(jù)核對，確保當月的數(shù)據(jù)上下游一致。

4.4 數(shù)據(jù)聚合

圖（4-2）商家對賬頁面

商家對賬的頁面如圖4-2所示，可以看出，對于帳房系統(tǒng)的要求是需要按照商家維度查詢對應的財務數(shù)據(jù)，同時需要按照月份進行聚合，返回商家每一個月的收入/支出金額。在使用es進行聚合查詢時，需要關注以下信息，保障查詢的效率。

聚合查詢字段，設置為keyword，能夠提升查詢的效率。（當前系統(tǒng)數(shù)據(jù)量下，查詢時間差異在2倍左右。）

es查詢時must和filter的使用，must 返回的文檔必須滿足must子句的條件，并且參與計算分值；filter 返回的文檔必須滿足filter子句的條件。但是跟must不一樣的是，不會計算分值， 并且可以使用緩存。簡單來講，filter查詢效率高于must，根據(jù)自己的實際業(yè)務場景選擇合適的查詢語句，在不需要相關性算分的查詢場景，盡量使用filter context讓查詢更高效。（當前系統(tǒng)數(shù)據(jù)量下，查詢時間差異在2-4倍左右。）

ES中的路由（routing）機制決定一個document存儲到索引的哪個shard上面去，即文檔到shard的路由。計算公式為：shard_num = hash(_routing) % num_primary_shards。一般情況下，不建議使用寫入時設置routing，如果routing設置的不合理，會導致數(shù)據(jù)傾斜的問題，數(shù)據(jù)傾斜會導致查詢問題以及集群不穩(wěn)定。若能夠保證設置的routing分布均勻，且使用routing作為數(shù)據(jù)隔離方式，在這樣的情況下，后面檢索的時候，同樣使用隔離參數(shù)作為routing，就可以精準的從某個shard獲取數(shù)據(jù)了，提升查詢的效率。早期帳房系統(tǒng)使用商戶ID作為routing，在一定程度上提升了查詢的效率，但是隨著業(yè)務的增加，出現(xiàn)了熱點商戶的問題，導致了es數(shù)據(jù)傾斜問題，從而引起了一些問題，后續(xù)進行了數(shù)據(jù)的遷移，不再使用資金池id作為routing，而是使用系統(tǒng)默認的文檔id作為routing。

es深分頁問題，es分頁查詢有三種方式：1.form size 。2.scroll方式。3.search after方式。這里簡單做一下對比，查詢速度上scroll>search after>form size。帳房系統(tǒng)設計中三種查詢方式均有使用，適用于不同的場景，form size方式用于前端頁面上的展示，僅僅展示少量的分頁數(shù)據(jù)；scroll查詢方式用于大量數(shù)據(jù)的文件導致任務，快速完成文件的導出任務；search after方式用于對外的API批量數(shù)據(jù)導出，業(yè)務側可重復獲取某一頁數(shù)據(jù)進行處理。

五、結束語

基于當前交易中臺所支撐的業(yè)務場景，建立了如上的帳房系統(tǒng)，我們也在不斷的進行完善和升級，助力上游的業(yè)務不斷的前進，提升商家的對賬體驗。隨著業(yè)務的不斷發(fā)展，帳房系統(tǒng)也在不斷的進行升級改造，不斷地完善自身。后續(xù)我們將持續(xù)升級系統(tǒng)，與業(yè)務共同發(fā)展成長。

參考資料

【1】百度交易中臺之訂單系統(tǒng)架構淺析?

https://mp.weixin.qq.com/s/olILeDhU4imO2AR446lP9Q

【2】百度交易中臺之商品推廣流程構建以及實現(xiàn)

https://mp.weixin.qq.com/s/vY_TdNclvhtwxLxjKWfwrg

總結

以上是生活随笔為你收集整理的百度交易中台之账房系统架构浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。