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

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

一、系統(tǒng)介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

• 收入：指分帳流水

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

• 支出：指打款流水

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

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

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

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

例子說(shuō)明

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

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

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

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

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

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

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

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

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

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

帳房系統(tǒng)業(yè)務(wù)需求為商家/用戶對(duì)賬需求，主要是為了滿足商家/用戶對(duì)于財(cái)務(wù)相關(guān)的對(duì)賬數(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ù)庫(kù)分度分表的方式進(jìn)行的，這樣的方式并不適用于帳房系統(tǒng)，引入分表的方式會(huì)導(dǎo)致數(shù)據(jù)不均勻的情況產(chǎn)生，對(duì)于熱點(diǎn)賬戶的問(wèn)題難以解決，同時(shí)難以完成多維度的數(shù)據(jù)查詢。基于此系統(tǒng)采用了es的存儲(chǔ)方式，通過(guò)es支持對(duì)外的多維度、準(zhǔn)實(shí)時(shí)的數(shù)據(jù)查詢。

帳房系統(tǒng)早期的數(shù)據(jù)寫(xiě)入時(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)寫(xiě)入失敗的情況。因此系統(tǒng)進(jìn)行了es數(shù)據(jù)遷移，從而解決數(shù)據(jù)傾斜的問(wèn)題。同時(shí)Elasticsearch 使用一種稱為倒排索引的結(jié)構(gòu)，它適用于快速的全文搜索，因此es對(duì)于字段的變更修改無(wú)法直接在原來(lái)的索引上進(jìn)行，都是重建索引，進(jìn)行數(shù)據(jù)的遷移完成的。es數(shù)據(jù)的遷移方式有很多（BOS快照遷移、Logstash、通過(guò)Spark遷移數(shù)據(jù)、HDFS快照遷移等），鑒于交易側(cè)es數(shù)據(jù)量以及遷移的場(chǎng)景，使用了Logstash同步的方式進(jìn)行了數(shù)據(jù)的遷移，遷移過(guò)程中將文檔的routing設(shè)置去除，解決了數(shù)據(jù)傾斜的數(shù)據(jù)。

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

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

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

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

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

圖（4-2）商家對(duì)賬頁(yè)面

商家對(duì)賬的頁(yè)面如圖4-2所示，可以看出，對(duì)于帳房系統(tǒng)的要求是需要按照商家維度查詢對(duì)應(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ì)算分值， 并且可以使用緩存。簡(jiǎn)單來(lái)講，filter查詢效率高于must，根據(jù)自己的實(shí)際業(yè)務(wù)場(chǎng)景選擇合適的查詢語(yǔ)句，在不需要相關(guān)性算分的查詢場(chǎng)景，盡量使用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。一般情況下，不建議使用寫(xiě)入時(shí)設(shè)置routing，如果routing設(shè)置的不合理，會(huì)導(dǎo)致數(shù)據(jù)傾斜的問(wèn)題，數(shù)據(jù)傾斜會(huì)導(dǎo)致查詢問(wèn)題以及集群不穩(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)商戶的問(wèn)題，導(dǎo)致了es數(shù)據(jù)傾斜問(wèn)題，從而引起了一些問(wèn)題，后續(xù)進(jìn)行了數(shù)據(jù)的遷移，不再使用資金池id作為routing，而是使用系統(tǒng)默認(rèn)的文檔id作為routing。

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

五、結(jié)束語(yǔ)

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

參考資料

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

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

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

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

總結(jié)

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

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