共计 3266 个字符，预计需要花费 9 分钟才能阅读完成。
作者|伍振河
本文以博时基金的金融场景为案例，论述 RocketMQ 在晋升客户陪伴效率和丰盛金融场景化能力等方面的晋升作用。
行业背景
基金公司的外围业务次要分为两局部，一部分是投研线业务，即投资治理和行业钻研业务，它体现了基金公司外围竞争力。另一部分是市场线业务，即基金公司利用自身渠道和市场能力实现基金销售并做好客户服务。
博时基金管作为中国边疆首批成立的五家基金治理公司之一，截至 2021 年 6 月 30 日，博时基金公司共治理 276 只公募基金，治理资产总规模逾 15482 亿元人民币，累计分成逾 1465 亿元人民币。
随着互联网技术倒退，基金销售渠道更加多元化，线上成为基金销售重要渠道。相比传统基金客户，线上渠道具备客户基数大，程度参差不齐的特点。对于那些还不成熟的客户，咱们须要做好陪伴，让他们了解危险，了解投资。
RocketMQ 在陪伴体系中的利用
1、陪伴场景概述
博时基金建设了一套全方位多层次陪伴体系，从用户层面、市场层面和产品层面为用户提供投前、投中、投后的有温度的投资陪伴体验。
每个陪伴场景的达成，须要公司多个部门不同团队协同配合来实现。依赖与投研、合规、经营、大数据等上下游多个零碎。但这些零碎可能采纳不同技术架构，实现形式各异，如果采纳同步调用形式来实现协同，耦合度太高，不利于将来扩大。
2、RocketMQ 解耦异构零碎
RocketMQ 提供高效牢靠的消息传递个性和公布订阅机制，非常适合用于这种上下游异构零碎间的解耦。咱们把原来基于文件、邮件的合作形式全副线上化、流程化和机制化，大大晋升了陪伴输入效率。对于这种波及多方零碎的合作，须要对音讯进行正当地归类，以便进行过滤和索引。RocketMQ 提供的 Topic 和 Tags 就是用来做这件事的。
3、Topic 和 Tags 最佳实际
Topic 与 Tag 作为业务上用来归类的标识，别离属于一级分类和二级分类，这种层次化的分类标识与企业组织架构比拟相似，能够联合起来实现音讯过滤。举个例子，对于陪伴零碎的 Topic，经营零碎订阅经营类音讯，咱们给这类音讯打上 TagA 的标签，客服零碎订阅客服类音讯 TagB，陪伴编排零碎订阅编排类音讯 TagC，合规零碎须要对经营和陪伴音讯进行合规审查，因而它须要订阅 TagA 和 TagC，最初是数据中心，所有的音讯都要解决，因而它须要监听所有 Tag。
RocketMQ 事务音讯的金融利用场景
1、金融场景概述
接下来，咱们解说一下典型的金融场景 – 优惠购。在博时基金 APP 上申购基金能够享受低至 0 折的费率优惠，具体业务怎么样实现？这里有有两种形式，第一种先充值博时钱包，底层是替客户购买了一笔货币基金，而后再用博时钱包购买指标基金。这种形式须要用户操作两次，比拟繁琐，容易引起客单散失。另外一种形式就是优惠购，把两步购买基金封装成一次事务操作。对投资者来说，开启优惠购服务后，操作少一步，投资更简略！
2、畛域事件实践模型
畛域事件是指业务流程的一个步骤将导致进一步的业务操作，比方说登录事件，比方说基金购买事件等。在畛域模型外面，畛域事件事务采纳的是最终一致性，区别于强一致性，它是弱一致性的一种。在畛域模型映射到微服务零碎架构时，微服务之间的数据不用要求强统一，因而畛域事件能够解耦微服务。根据是否跨微服务，能够分为两种场景：
第一种场景：当畛域事件产生在同一个微服务。因为大部分事件产生在同一个过程内，本身能够很好地管制事务。但如果一个事件须要同时更新多个聚合，依照 DDD 中一次事务只更新一个聚合的准则，就须要引入事件总线，就是 eventbus 这种模式。
第二种场景：跨微服务。畛域事件产生在微服务之间的场景比拟多，事件处理的机制也更加简单。跨微服务的事件能够推动业务流程或者数据在不同的子域或微服务间间接流转，因而须要一个协调者来推动全局事务。跨微服务的事件机制要总体思考事件构建、公布和订阅、事件数据长久化、消息中间件、分布式事务机制等，其中具备事务音讯性能的消息中间件是这个解决方案的外围组件。
3、布式事务计划比照
在博时基金的业务场景下，须要解决的问题是事务一致性与服务解耦度之间的矛盾，因而咱们的指标是让主从事务解耦，保障外围逻辑稳固，同时不因为解耦而就义最终一致性。因而，过后做出了几种不同的解决方案：
- 第一种计划：最常见一般音讯 + 异步对账，这个计划的问题是无奈保障主事务的执行和入队同时胜利，须要时效性低的对账弥补解决，一致性只是较高。
- 第二种计划：本地音讯表，比照上一种做法，它由业务将写入音讯表放到主事务中，把主事务和入队变成一个原子操作，而后业务读取入队记录，本人投递给从事务。它的毛病是主事务和音讯表在存储上是耦合的，没有解耦度。
- 第三种计划：引入 XA 事务，是个两阶段提交的协定，实现难度较大。而且面临两个问题：一是这是一种同步阻塞协定，有锁占用导致并发不会太高，另外就是 XA 事务过程中，在参与者投赞成票后，如果协调者产生故障，节点不分明应该提交还是停止，只能期待协调者复原。这时候可能会呈现业务中断。
- 第四种计划：TCC，专门解决分布式事务的 TCC，只侧重于一致性，无解耦度，也是不可行。
- 第五种计划：事务音讯，它能同时兼顾解耦度和一致性，是最合适的模式。
最终咱们抉择了 RocketMQ 的事务音讯作为分布式事务的解决方案。
4、RocketMQ 事务音讯外围流程
基于 RocketMQ 的事务音讯搭建事务核心，协调分布式事务的推动和回滚。以优惠购为例，外围流程如下：
- 第一阶段：Prepare 阶段，即业务零碎将 RocketMQ 的半事务音讯发送到事务核心，事务核心不做公布，期待二次确认。这个阶段 RocketMQ 的半音讯在消费者端是感知不到的。
- 第二阶段：业务零碎执行主事务，即购买货币基金。
- 第三阶段：主事务胜利后 commit 到事务核心，由事务核心投递音讯到从事务。如果主事务失败，就投递 rollback 给事务核心。这里须要两阶段提交的起因是：一般的入队操作无论放在主事务之前还是之后都无奈保障最终统一。如果先执行主事务，再入队，那么可能在入队前，业务会宕机，就没有机会再入队了。如果先入队再执行主事务，那么可能主事务没有执行胜利，然而从事务执行胜利了，业务逻辑就会产生错乱。
因为网络抖动等起因，可能导致事务音讯的二次确认失落。此时须要依赖某种机制复原整个分布式事务的上下文，RocketMQ 提供的反查机制正是为解决分布式事务中的超时问题而设计的。咱们的事务核心的反查机制流程次要是，先查看事务核心的外部状态，再通过反查接口查看本地事务的执行后果，复原事务上下文后，失常推动后续的流程。
5、RocketMQ 如何保障事务音讯在生产端失常生产
生产端生产失败后，MQ 服务端须要进行肯定次数的重试，咱们须要制订正当的重试策略。因为有生产重试，这要求生产方接口须要实现幂等性；如果重试屡次后仍失败，咱们会把音讯压入死信队列 DLQ，RocketMQ 提供了死信队列的性能，对进入死信队列的音讯进行告警解决。
6、事务音讯的实用场景、
第一类场景：须要同步执行的畛域事件，比如说畛域事件逻辑失败概率大，业务要及时将返回码告知客户端，天然不能放在异步流程中。举个例子，做过领取零碎的小伙伴都晓得，领取扣款前要查看余额是否足够，如果余额有余，那在异步流程中重试多少次都是失败。
第二类场景：是事务不可重入场景，例如业务零碎发送音讯时没有确定一个惟一事务 ID，那后续的业务逻辑就无奈保障幂等，假如其中一个事务是创立订单，如果不能保障幂等的话，重试屡次就会产生多个订单；所以这里须要应用到事务音讯，用来明确一个分布式事务的开始，生成一个惟一事务 ID，让后续的流程能以这个事务 ID 来保障幂等。
将来布局
目前，咱们基于 RocketMQ 在客户陪伴体系上解耦了上下游的服务，晋升了经营和陪伴的效率。同时，咱们在 RocketMQ 事务音讯的根底上，搭建了这样一个反对分布式事务的服务协调平台，也就是咱们的事务核心，大大晋升了对金融场景化的产品包装能力。将来，咱们将围绕着事务核心，拓宽更多的金融利用场景，发明更大的业务价值。
