共计 6071 个字符，预计需要花费 16 分钟才能阅读完成。
导读 ：百度 APP 内含有现金、流动、虚构等多类资产信息，散布于百度 APP 内各个业务线中，用户回访信息难度较高，且用户对百度资产认知度不高。我的钱包建设后，汇聚百度 APP 内所有用户资产信息，解决了用户回访难的问题，建设用户百度 APP 资产认知。本文次要介绍了钱包从 0 到 1 的搭建过程、遇到的各种问题以及相应的解决方案，旨在抛砖引玉，心愿能给读者带来思考和帮忙。
全文 6082 字，预计浏览工夫 16 分钟
一、背景
百度 APP 坐拥日活 2 亿 +、月活 6 亿 + 用户，在百度 APP 内每时每刻都产生了泛滥用户的资产信息。以后，百度 APP 内含有现金资产、流动资产、虚构资产等多类资产信息，散布于百度 APP 内各个业务线中。每个业务线提供用户独立的资产信息，业务线间关联性较低，用户回访信息难度较高，不利于造成用户对百度 APP 资产信息的整体认知。亟需一个零碎，可能汇聚百度 APP 内所有用户资产信息，反对用户资产信息对立汇总、展现，收拢用户回访入口，建设用户百度 APP 资产认知，晋升百度 APP 用户体验，我的钱包应运而生。
二、业务介绍
百度 APP 集体中心里我的钱包，次要收拢了百度用户的资产信息，进行对立的治理、展现，同时收拢各个业务线资产查看、应用等能力的入口，便于用户疾速回访、找到集体的资产信息。钱包在百度 APP 集体核心外露四个金刚位和钱包入口地址，四个金刚位反对配置，经营人员可依据不同期间的流动、营销等配置不同外露业务方，便于用户快捷回访。同时四个金刚位反对业务数据外露展现，使用户直观感知集体的资产信息。
在钱包入口点击后，可进入钱包首页。首页中次要外露用户的现金、提现流动、返现、卡券、虚构币、快捷入口等信息，同时反对经营配置营销、流动。对于现金余额信息，咱们须要用户受权，用户受权后查问用户在度小满、百度闪付的余额，进入明细页面后，可别离进行受权、查看明细。针对流动提现金额，钱包推动百度 APP 内所有波及提现金额的业务接入钱包，对立进行治理，反对用户查看金额明细，其中金额明细中蕴含两个局部，一部分是明确返回用户余额信息的业务，反对用户点击跳转至具体业务方查看明细，另一部分是汇总百度提现核心全副业务，反对用户点击跳转，建设用户现金余额对立治理、拜访的认知。对于虚构币数据，可依据用户各个虚构币余额数量进行动静展现，便于用户疾速通晓本人的虚构币信息，点击具体虚构币时，反对跳转至业务方明细页面进行查看明细、充值等操作，也反对跳转至钱包对立虚构币明细列表，查看用户明细、月度汇总等信息。对于业务方接入，钱包提供多种接入形式：API 数据同步、实时查问、配置跳转，业务方可依据本人理论状况进行抉择。
△图 2 -1 钱包展现
三、零碎业务架构
△图 3 -1 钱包业务架构图
钱包的整体零碎业务架构如上图 3 - 1 所示，钱包服务次要面向 C 端用户、业务接入方、经营人员。针对 C 端用户，钱包提供百度 APP 集体核心一级入口和钱包首页两个外围入口，前端应用 talos 框架实现。用户通过集体核心入口拜访达到逻辑层后，首先判断用户是否命中用户缓存，该缓存用来标识用户是否有资产，如果命中缓存且有资产，则读取数据缓存返回数据。用户通过钱包首页进入钱包，依据拜访的模块，路由适配器依据配置规定，抉择不同数据规定进行数据加载、获取，数据获取后按规定进行聚合返回。为了避免服务异样时影响页面渲染，提供异样兜底计划，业务方接口异样时应用缓存数据兜底，外部异样时对立返回兜底文案。
针对不同的业务方，咱们提供多种接入形式，对一个人核心一级入口外露业务，咱们提供推送、拉取机制，即业务方在用户数据变更时同步钱包，钱包准时拉取用户最新数据；对于钱包首页、列表页业务，咱们提供实时查问形式，对于利用钱包给业务内导流的业务，咱们反对 H5、scheme、talos、端内等多种跳转能力。配置次要包含根底配置、扩大配置、流控配置，实现不同的适配器供上游调用。
经营人员可应用 B 端经营工具，配置、批改接入的业务方信息，也能够治理钱包首页展现、经营流动、营销等，同时亦可配置相干的流控、监控等信息。底层服务，咱们应用了百度内通用的数据库、Redis、音讯队列、CDN 等根底服务，该根底服务由对立的部门运维，稳定性比拟牢靠。
四、技术细节
1、资产数据同步
钱包搭建，面临着一个辣手的问题：百度 APP 内资产信息散布在不同业务线，信息间相互隔离，零碎异构。如果推动业务方间接裸露 API 查问数据，则须要业务方接口达到钱包要求的高 QPS、底平响、高稳定性，同时业务线内可能存在一些非凡状况，再加上节假日、流动等非凡期间流量突增，会重大影响钱包数据展现，进而影响用户体验。存在局部业务方用户量级较小，但必须得提供合乎钱包须要的性能，这就对业务方带来额定压力。如果要求所有业务方将全量数据同步至钱包，又面临业务线数据推送、钱包海量数据存储、数据准确性对账等问题。
针对如上一系列问题，咱们确定了接入钱包的准则：①在集体核心破壳展现位外露的业务方，必须将资产数据同步至钱包，钱包服务外部确保接口可用性和降级计划；②钱包首页展现数据，反对业务方抉择是否将数据同步至钱包，如果不同步数据，须要提供满足 QPS、平响等要求的 API 供钱包调用；③钱包二级页面、三级页面数据，需业务方提供查问 API 或者落地页，实时查问业务方数据进行展现，确保明细数据准确无误。
1.1 数据同步
对于业务方同步的用户资产数据，咱们只存储用户的最新数据，思考数据量级问题，钱包不存储历史快照。钱包定义业务方数据推送的接口标准，业务方在数据更新时，需及时告诉钱包拉取最新数据。为了避免业务方推送数据时流量突增对钱包 sever 的影响以及进步钱包 server 的吞吐，引入音讯队列进行削锋，即接到业务方资产数据变更申请时，放入音讯队列后返回业务方告诉胜利，钱包 server 内生产队列音讯，依据配置信息向业务方拉取最新数据进行更新。对于用户资产明细数据，钱包定义接口标准，业务方实现后将调用地址提供给钱包，钱包进行配置，用户拜访时实时调用。
于是，咱们设计了如下的数据同步计划：
△图 4 -1 业务方数据同步
①用户资产变更时，业务方调用钱包接口告诉信息变更；
②钱包接到告诉后，放入音讯队列；
③生产工作获取音讯队列中音讯进行生产解决；
④依据配置，拉取业务方最新信息，更新至钱包存储；
在生产音讯时，钱包 server 进行批量解决，针对肯定工夫内同一业务方同一用户信息，只拉取一次数据，缩小对业务方服务压力。遇到异样时，会进行 3 次重试拉取。钱包 server 管制是否拉取、流控，在上游业务方服务异样时，可及时进行拉取、升高拉取流量，缩小或者去除上游系统对钱包的影响。
1.2 实时查问
针对局部业务方不推送数据，咱们定义接口标准，业务方进行实现，实现后上报钱包配置调用形式。对于此类业务方，不容许配置到集体核心展现，避免业务方接口性能不达标连累整体用户体验。实时查问接口次要分为余额、分页明细接口，钱包对立 format 后进行展现。余额接口查问返回后，异步写入 Redis 进行缓存，用于下次访问业务接口异样时进行兜底展现，如果后续拜访业务接口失常，则应用最新数据更新 Redis 数据。
用户明细分页数据蕴含分页明细数据和月度汇总数据（月度总收入与总支出），钱包调用上游拆分成两个接口：分页明细接口和月度汇总接口，提供给前端展现页面封装成一个接口，升高前端交互复杂度。调用上游分页接口实时返回用户明细分页数据，月度汇总接口返回用户以后明细所属月份的汇总数据。钱包服务外部依据业务方明细分页接口数据进行汇总，为了缩小申请业务方次数，钱包外部判断分页数据，如果返回数据都是同一月份，则只申请业务方一次月度汇总接口，后续分页不再申请，如果返回数据扩散在两个月份，则申请业务方月度接口两次，如果返回数据扩散在三个月份（含）以上，则只申请起止两个月份的月度数据，两头月份数据由钱包依据明细数据外部计算。
2、多级缓存
百度登录账号体系中，用户 id 已超过数十亿，存在资产的用户靠近亿级，同时钱包会在百度 APP 集体核心破壳展现局部业务，即一级入口，预计会带来均匀万级 QPS、峰值超过十万级 QPS 流量，非凡工夫点可能会更高。为了避免服务宕机对百度 APP 产生非预期影响，故须要对破壳展现的数据提供残缺缓存计划和降级预案。为了晋升零碎的高吞吐，咱们决定将一级入口数据全副缓存至 Redis，拜访流量只读 Redis，如果遇到 Redis 异样时，则返回兜底数据，不查问 DB（避免压垮 DB）。DB 数据用来 Redis 极其状况解体时复原 Redis 数据时应用。
针对存在资产的用户量剖析，进入集体核心的用户存在一个特点：大部分用户没有集体核心外露的资产数据，形象成一个稠密矩阵，这就使咱们在设计的时候，能够思考两层缓存：第一层判断用户是否领有资产信息，第二层缓存存储用户资产数据。故咱们设计了如下的两层缓存计划。
△图 4 -2 钱包两层缓存计划时序图
大部分用户流量会被第一层缓存拦挡，设计正当的第一层缓存数据构造，成为了零碎的一个要害。咱们调研了 hyperLogLog、布隆过滤器、roaringBitmap 等计划，剖析和试验后发现，hyperLogLog 中 pfadd 操作自身能够满足性能要求，key 的大小在 12k 也满足，然而因为 pfadd 自身针对于一个 uid，只能操作一次，所以不适宜这个场景 hyperLogLog；布隆过滤器在试验 20 亿的数据量下，内存占用来量大概占比 3G，内存占用比拟大，基于 redis 的布隆过滤器没有分布式的数据能力，实质上还是对 redis 的强依赖，存在危险。
roaringBitmap 在存储空间上满足要求，咱们依据钱包的理论场景，改良了分桶与计算规定，依据用户 id 进行 sharding 分桶，桶内应用 uid 的 hash 值对应的 bitmap 位点标记状态。试验数据验证，3000 分片，8 个计算单元，1000W 试验数据，存储空间占用 500M+，误判率 2.14%，即存在 2.14% 的用户没有资产信息会打到第二层缓存，整体对第二层缓存减少压力可控。
3、读写拆散
钱包服务承接较大的读流量和写流量，为了避免相互影响，咱们将读写流量别离拆到不同的服务。用户拜访读服务异样时，不影响业务方推送写入，业务方推送写入服务异样时，不影响 C 端用户拜访。读服务次要承接 C 端用户通过集体核心和钱包首页、二级页面拜访的流量，将用户拜访的相干数据进行缓存，晋升零碎平响。写服务次要承接业拉取业务方数据和 C 端用户受权信息，同时承接音讯队列生产解决和与上游业务方交互。读写服务之间，通过 RPC 接口调用进行交互。
△图 4 -3 读写拆散
4、数据统一
集体核心外露的业务数据，针对接入用户核心外露展现的业务方，咱们须要业务方在用户资产产生变更时及时推送给钱包，以确保用户在钱包看到的数据与在业务方提供的入口查看的数据是雷同的。但理论状况不肯定如此，比方业务方推送服务异样、网络抖动，都有可能导致两方数据不统一。于是，咱们提出了推拉联合的数据一致性解决方案。即业务方资产信息变更时，准时推送钱包，在用户进入集体核心时，触发拉取用户最新资产信息。以后，咱们只对用户的资产信息已被推送至钱包的业务方，拉取用户最新资产信息，避免拉取全量业务方数据给用户量级小的业务方带来过多有效拉取流量导致服务压垮。针对零碎外部，因为展现时只应用 Redis 中缓存数据，如果同步用户信息时因某些异样导致 Redis 与 DB 中数据不统一，咱们采纳定时工作，每天凌晨拉取 DB 中前一天（DB 变更工夫）有变更的用户信息，与 Redis 信息进行比对，数据不统一时，拉取业务方最新数据，更新 Redis 数据，做到 T + 1 对账，解决零碎内数据不统一问题。
对于钱包内展现的业务方，也会存在服务异样、网络抖动导致的无奈获取用户最新信息的问题。咱们采纳的计划，对于失常申请业务方后果数据，将后果信息写入 Redis，如果下次访问业务方接口异样时，应用 Redis 中数据作为兜底，优先确保数据失常展现。如果后续申请上游接口失常，则应用胜利的数据更新 Redis 数据，确保 Redis 数据的准实时性。
△图 4 -4 钱包数据统一计划时序图
5、配置化
钱包设计之初，就面临着如何反对业务方疾速接入和反对经营人员疾速配置用户展现界面、流动、营销等信息的问题。通用配置化能力，是解决此类问题的首选计划。
配置化次要分为两局部：接入配置化和展现配置化。通过剖析发现，不同业务方的接入、展现需要不同，于是咱们形象独特的信息，生成通用根底信息，对于业务个性化信息，采纳扩大模型记录业务非凡配置。汇总业务方根底配置 + 扩大配置后，放入 Redis 缓存中。对于钱包展现配置，底层设计展现通用配置，比方展现名称、文案、跳转链接、图片 Url、背景图 Url，对于非凡展现需要，可配置到扩大信息，比方外露 Icon、展现金额，配置信息同样放入 Redis 缓存中。
我的项目上线初期，配置信息新增与更改的频次都很高，容易产生批改谬误的危险，导致 C 端用户体验受损。于是咱们设计版本号 + 白名单计划进行放量管制，新版本公布需与白名单用户相关联，配置失效后先应用白名单用户线上进行验证，验证通过后逐渐全流量。批改配置时，保留历史更改全量数据，用于配置信息异样时回滚。
因为钱包对业务方配置信息依赖较强，如果 Redis 异样时会影响钱包的稳定性，所以咱们将配置信息同步配置到百度云控平台 GCP 中，作为 Redis 异样时的兜底。缓存有效期能够设置永恒无效，在变更配置时同步更新 Redis，同时须要同步更新 GCP 配置，及时下发。
6、数据库设计
因为用户量较大，波及用户资产信息到了数据库层面会同步放大，受限于 MySQL 数据库单机解决能力，故将数据进行拆分，不同的数据搁置在不同的机器，便于机器扩容。在数据模型的设计上，数据库分表字段采纳用户 id 作为分表字段（shardingKey），这样通过用户 id 定位到具体的库和表，因将整个资产信息库所有表依照对立规定进行切分，分表规定统一，保障依照同一用户都能在一个库，从而能够应用数据库事务。采纳分库分表模式，后续遇到数据库存储瓶颈时，能够很不便的进行横向扩容。
五、总结
本文重点在介绍了百度 APP 集体钱包搭建的整个技术细节，在我的项目推动和落地的过程中，也遇到了诸多困难，次要的难点在零碎高可用、高稳固、疾速反对业务接入。梳理分明难点与技术关键点，抓住关键问题，对系统正当做减法，升高零碎复杂度，疾速推动零碎上线，后续一直迭代，打造极致用户体验。后续，在业务上会继续推动业务线疾速接入，让用户在钱包内能够查看、治理百度系全量资产信息，在技术上持续推动稳定性、可靠性建设，为业务方带来更多用户流量，为用户提供更好的用户体验。
——————END——————
举荐浏览：
基于宽表的数据建模利用
百度评论中台的设计与摸索
基于模板配置的数据可视化平台
如何正确的评测视频画质
小程序启动性能优化实际
咱们是如何穿过低代码“⽆⼈区”的：amis 与爱速搭中的要害设计
挪动端异构运算技术 -GPU OpenCL 编程（根底篇）
云原生赋能开发测试
