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

全文5184字，預(yù)計(jì)閱讀時(shí)間14分鐘

一、系統(tǒng)介紹

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

二、業(yè)務(wù)場景

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

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

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

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

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

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

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

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

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

調(diào)整款流水：指打款銀行退匯的流水。

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

• 收入：指分帳流水

• 其他款項(xiàng)：包含交易中臺收取的技術(shù)服務(wù)費(fèi)、打款退回的流水、小程序帶貨流水以及宿主帶貨流水

• 支出：指打款流水

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

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

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

結(jié)算賬期對賬公式：收入 + 其他款項(xiàng) - 支出= 0

例子說明

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

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

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

三、系統(tǒng)構(gòu)架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、結(jié)束語

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

參考資料

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

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

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

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

總結(jié)

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

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