1.背景百度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、ping-ping等要求的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个人钱包搭建的整个技术细节，在项目推动和落地的过程中，也遇到了诸多困难，主要的难点在系统高可用、高稳定、快速支持业务接入。梳理清楚难点与技术关键点，抓住关键问题，对系统合理做减法，降低系统复杂度，快速推进系统上线，后续不断迭代，打造极致用户体验。后续，在业务上会持续推进业务线快速接入，让用户在钱包内可以查看、管理百度系全量资产信息，在技术上继续推进稳定性、可靠性建设，为业务方带来更多用户流量，为用户提供更好的用户体验。
