导读：百度交易中台作为团体挪动生态策略的基础设施，面向收银交易与清分结算场景，为赋能业务提供高效交易生态搭建。目前反对百度体系内多个产品线，次要蕴含：小程序，地图打车，百家号，招财猫，难看视频等。本文次要介绍了百度交易中台的商户财务对账相干的帐房零碎，次要从业务模型以及零碎设计来介绍该零碎。
全文 5184 字，预计浏览工夫 14 分钟
一、零碎介绍
帐房零碎是建设在百度交易系统 [1] 下，收拢聚合了商家 / 平台 / 宿主等接入方的支出 / 收入流水的对账零碎。商家通过该零碎可间接看到本人的支出 / 其余款项 / 收入等流水信息，实现按天 / 月 / 年的财务对账。
二、业务场景
针对不同业务背景，交易清结算零碎产生了不同的流水类型。目前支流的业务场景蕴含：1. 直播带货等场景下的流量主带货[2]。2. 小程序宿主内的宿主带货。3. 地图打车等业务场景下的平台分帐。
图（2-1）交易中台业务背景
这些业务场景下，交易流水产生的过程如图（2-2）所示。一个订单通过领取、领取告诉（购物车拆子订单）、订单维度结算、结算流水推送商家资金池，最初资金池流水才会到帐房零碎，交易流水产生在图（2-2）中的商家订单结算过程中，一个订单会产出多条交易流水，推送到上游资金池零碎进行商家账户记账，同时产生了对应的资金池流水，帐房零碎的数据起源就是资金池的流水记录。目前商家结算产出流水类型有以下几种：
图（2-2）交易流水产生流程
- 分帐流水（货款）：对于入驻交易的平台方，平台方为商家提供了平台上的性能，平台方冀望从商家售卖的货款中收取肯定的佣金，作为平台的支出。基于这种业务场景，产生了平台的分帐流水。对应图（2-2）商家结算中的分帐形式产出，分帐形式蕴含：依照固定比例，依照固定金额，自主比例分帐以及多方分帐，接入方依据理论的业务场景抉择对应的分帐形式。
- 技术服务费：技术服务费为交易中台（网讯主体）对应用收银台领取的商家，会收取肯定比例的钱作为技术服务费，因而产生了对应的技术服务费流水，对应图（2-2）商家结算中的分帐形式的佣金模式产出，佣金模式蕴含：固定比例、固定金额以及依照渠道收取。对应商家的其余款项数据。
- 小程序带货流水：小程序带货流水为流量主收取的带货佣金，流量主为商家通过文章、视频、直播带货后，卖出的货款会分一部分给带货的流量主，从而产生了小程序带货流水。与分帐流水不同的时，分帐的流水是给入驻的平台，而带货流水最初的结算对象是集体。
- 宿主带货流水：业务背景是智能小程序开源联盟，为宿主和小程序共建生态。宿主为小程序提供散发流量及展示入口，无效晋升小程序的应用时长及频次，基于此，宿主产生对在其 APP 上产生的交易进行抽佣的诉求，从而实现宿主新商业变现模式拓展，带动宿主商业支出增长。宿主带货流水的产生形式与小程序带货相似，区别是宿主在交易进行和入驻，属于企业 / 公司类型。一个商家属于一个平台，也能够和宿主进行绑定，与二者同时进行分账。
- 打款流水：打款流水为给商家银行卡打款的流水。
- 调整款流水：指打款银行退汇的流水。
帐房零碎将以上的流水划分为 3 个类别：支出、收入以及其余款项。
- 支出：指分帐流水
- 其余款项：蕴含交易中台收取的技术服务费、打款退回的流水、小程序带货流水以及宿主带货流水
- 收入：指打款流水
商家整体财务数据核查收支平衡的公式为：
总体对账公式：商家余额 = 支出 + 其余款项 – 收入
若公式成立则收支流水数据准确无误。若商家想要核查账期内的财务数据，则须要看两个账期之间的支出和收入是否统一。例如商家每隔 7 日进行一次打款（即是收入），则商家只须要核查这 7 天内的流水数据是否满足以下公式即可。
结算账期对账公式：支出 + 其余款项 – 收入 = 0
例子阐明
交易中台所反对的业务场景中，一个订单会产生多条流水，每一条流水的结算对象也不一样，因而，这里举例简略阐明流水属于的对象。
例子：针对小程序带货的场景，一个订单金额为 100 元，带货流量主分佣 10%，平台分帐 5%，交易中台收取 6‰技术服务费。因而各个对象的流水金额如下：
从表中能够看出最初的总金额只有 84.4+10+5=99.4 元，短少的 0.6 元就是交易中台收取的技术服务费。技术服务费的收取是通过从商家口扣除 0.6 元实现的，而不是产生 0.6 元的流水给交易中台。如果打款周期到了，对应给结算对象的打款金额就别离为 84.4 元，10 元和 5 元，这样支出和收入就统一了。
三、零碎构架
图（3-1）帐房零碎架构图
帐房的整体架构如图 3 - 1 所示，帐房的数据起源为上游的资金池流水数据，canal 监听 binlog，解析 binlog 日志将流水数据公布到 bigpipe，帐房零碎通过监听 bigpipe 数据，拿到流水数据后通过 akka 实现数据的校验、补充，失去一条齐备的流水数据。最初通过 esClient 将流水数据写入百度云 es，业务的查问以及导出性能都是基于百度云 es 的数据来实现的。与此同时，交易中台也建设了离线计算零碎，通过 spark 拉取 es 的集群数据，存储在 AFS 上，基于此实现离线数据统计的性能。帐房零碎以资金池流水数据为主，依据流水类型的不同，补充了来自其余不同零碎的数据，丰盛该条流水的信息，来满足业务侧查问的需要，补充的数据存储在 es 以及数据库中，针对热点的数据，零碎应用 LoadingCache 本地缓存的形式晋升处理速度。零碎对外输入数据的形式有：第三方 API、电商开放平台、财务经营平台、业务商家后盾以及 AMIS 发票零碎。
四、零碎性能拆解
4.1 基于 canal 的数据同步
帐房零碎的数据起源为上游账户资金池零碎的流水数据，资金池流水数据存储在 ddbs 数据库中。帐房须要实现准实时数据的获取，同时防止代码的侵入，因而采纳了基于 cacal 监听 ddbs 数据库 binlog 日志的形式，进行数据的同步；因为每日的流水产生存在流量顶峰，间接将数据申请上游帐房零碎，可能会对帐房零碎产生冲击，引起零碎异样的问题。为了防止这种状况的呈现，咱们引入了中间件音讯队列（bigpipe）进行流量削峰填谷解决，canal 将解析的库表变更数据发送到音讯队列中，帐房零碎采纳监听者模式从音讯队列中获取对应的数据，通过 java 的 akka 形式进行并发的数据处理。帐房零碎通过异步音讯以及 akka 并发的形式实现数据的异步化同步，解决流量顶峰问题，实现了数据的准实时同步，以后零碎的数据同步延时管制在秒级别。
4.2 Elasticsearch 数据存储
帐房零碎业务需要为商家 / 用户对账需要，次要是为了满足商家 / 用户对于财务相干的对账数据的查问以及导出。基于这样的特点，须要查问大量的数据，同时须要实现各个维度的数据聚合，而且商家的流水数据量远大于订单的数据量，一个订单将会产生 2 - 6 条的流水。交易订单核心以及上游账户资金池零碎的存储都是采纳数据库分度分表的形式进行的，这样的形式并不适用于帐房零碎，引入分表的形式会导致数据不平均的状况产生，对于热点账户的问题难以解决，同时难以完成多维度的数据查问。基于此零碎采纳了 es 的存储形式，通过 es 反对对外的多维度、准实时的数据查问。
帐房零碎晚期的数据写入时自定义了 routing，应用商家 id 作为 routing，随着业务倒退，热点商户的数据量一直减少，从而导致 es 分片呈现了数据歪斜的状况，进而会引发 es 聚合查问偶发超时以及偶现写入失败的状况。因而零碎进行了 es 数据迁徙，从而解决数据歪斜的问题。同时 Elasticsearch 应用一种称为倒排索引的构造，它实用于疾速的全文搜寻，因而 es 对于字段的变更批改无奈间接在原来的索引上进行，都是重建索引，进行数据的迁徙实现的。es 数据的迁徙形式有很多（BOS 快照迁徙、Logstash、通过 Spark 迁徙数据、HDFS 快照迁徙等），鉴于交易侧 es 数据量以及迁徙的场景，应用了 Logstash 同步的形式进行了数据的迁徙，迁徙过程中将文档的 routing 设置去除，解决了数据歪斜的数据。
4.3 数据一致性保障
帐房零碎其次要性能为商家的对账，因而商家的流水数据的缺失必然会导致商家财务数据的谬误，给商家带来对账上的问题。因而保障帐房的数据与上游零碎统一，是该零碎重要且必须的能力。数据一致性的保障，帐房零碎通过接入交易平台的一致性服务零碎实现，其流程如图 4 - 1 所示。
图（4-1）数据一致性保障流程图
一致性服务通过接管来自上游 canal 发送的 bp 音讯，以及帐房零碎写入 es 胜利后发送的 bp 音讯，将二者的音讯存储至 mysql 数据库中，每日定时对上下游零碎的数据进行比照剖析，得出对应的差别数据，而后通过调用对应的修复接口实现数据的修复。一致性服务留存了 7 日内的音讯数据，过期定时清理，保障服务的数据量不会过大，不影响数据库性能。除了一致性服务的保障之外，每月会通过 spark 进行离线数据核查，确保当月的数据上下游统一。
4.4 数据聚合
图（4-2）商家对账页面
商家对账的页面如图 4 - 2 所示，能够看出，对于帐房零碎的要求是须要依照商家维度查问对应的财务数据，同时须要依照月份进行聚合，返回商家每一个月的支出 / 收入金额。在应用 es 进行聚合查问时，须要关注以下信息，保障查问的效率。
聚合查问字段，设置为 keyword，可能晋升查问的效率。（以后零碎数据量下，查问工夫差别在 2 倍左右。）
es 查问时 must 和 filter 的应用，must 返回的文档必须满足 must 子句的条件，并且参加计算分值；filter 返回的文档必须满足 filter 子句的条件。然而跟 must 不一样的是，不会计算分值，并且能够应用缓存。简略来讲，filter 查问效率高于 must，依据本人的理论业务场景抉择适合的查问语句，在不须要相关性算分的查问场景，尽量应用 filter context 让查问更高效。（以后零碎数据量下，查问工夫差别在 2 - 4 倍左右。）
ES 中的路由（routing）机制决定一个 document 存储到索引的哪个 shard 下面去，即文档到 shard 的路由。计算公式为：shard\_num = hash(\_routing) % num\_primary\_shards。个别状况下，不倡议应用写入时设置 routing，如果 routing 设置的不合理，会导致数据歪斜的问题，数据歪斜会导致查问问题以及集群不稳固。若可能保障设置的 routing 散布平均，且应用 routing 作为数据隔离形式，在这样的状况下，前面检索的时候，同样应用隔离参数作为 routing，就能够精准的从某个 shard 获取数据了，晋升查问的效率。晚期帐房零碎应用商户 ID 作为 routing，在肯定水平上晋升了查问的效率，然而随着业务的减少，呈现了热点商户的问题，导致了 es 数据歪斜问题，从而引起了一些问题，后续进行了数据的迁徙，不再应用资金池 id 作为 routing，而是应用零碎默认的文档 id 作为 routing。
es 深分页问题，es 分页查问有三种形式：1.form size。2.scroll 形式。3.search after 形式。这里简略做一下比照，查问速度上 scroll>search after>form size。帐房零碎设计中三种查问形式均有应用，实用于不同的场景，form size 形式用于前端页面上的展现，仅仅展现大量的分页数据；scroll 查问形式用于大量数据的文件导致工作，疾速实现文件的导出工作；search after 形式用于对外的 API 批量数据导出，业务侧可反复获取某一页数据进行解决。
五、结束语
基于以后交易中台所撑持的业务场景，建设了如上的帐房零碎，咱们也在一直的进行欠缺和降级，助力上游的业务一直的后退，晋升商家的对账体验。随着业务的一直倒退，帐房零碎也在一直的进行降级革新，一直地欠缺本身。后续咱们将继续降级零碎，与业务独特倒退成长。
参考资料
【1】百度交易中台之订单零碎架构浅析
https://mp.weixin.qq.com/s/olILeDhU4imO2AR446lP9Q
【2】百度交易中台之商品推广流程构建以及实现
https://mp.weixin.qq.com/s/vY\_TdNclvhtwxLxjKWfwrg
举荐浏览：
GDP Streaming RPC 设计
百度 APP 视频播放中的解码优化
百度爱番番实时 CDP 建设实际
当技术重构遇上 DDD，如何实现业务、技术双赢？
接口文档主动更改？百度程序员开发效率 MAX 的秘诀
技术揭秘！百度搜寻中台低代码的摸索与实际
百度智能云实战——动态文件 CDN 减速
化繁为简 – 百度智能小程序主数据架构实战总结
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边