![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/38f37e85f7ea4163abdbbc51edc23118~tplv-k3u1fbpfcp-zoom-1.image)

*作者：RocketMQ*

作为解决海量消息堆积以及电商场景下精准顺序消息分发的消息队列项目，Apache RocketMQ 伴随多年发展，已成为电商、金融、科技等领域技术中台的最核心底座。据不完整统计，国内金融 Top100、保险 Top100、券商 Top50 中，超过 70% 机构或企业在核心应用链路上规模化部署了 RocketMQ。由于行业特殊性，金融行业有着最为严苛的技术与可用性要求，对于众多企业而言极具参考价值。那么，今天我们来聊聊金融行业如何进行消息队列选型。

随着软件系统的复杂度越来越高，故障是不可避免的。这就需要企业的整体架构具备弹性，为应对故障而设计。然而，常见的 RPC、RMI 企业集成技术，由于同步请求而时常因执行方失败、超时等因素而影响最终用户体验，且很多故障无法彻底消除。而 RPC 和 RMI 调用需要服务消费方和服务提供方同时在线，并双方需要通过某种机制确认调用关系，因为存在这些弊端，就导致了面向消息的中间件（MOM）的产生，通过引入消息中间件，确保在故障发生时，受此影响的系统部分在很小范围内。

## 消息队列优势

消息队列作为不同应用程序之间(跨进程)的通信方法，用于上下游应用程序之间传递消息，实现上游与下游的解耦。上游向 MQ 发送消息，下游从 MQ 接收消息，上游下游互不依赖，它们只依赖 MQ，MQ 可以把上游信息先缓存起来，下游根据自身能力从 MQ 中拉取信息，实现削峰作用。消息队列的优势不仅于此，还包括：****

**解耦**

在企业整体架构中为了实现高内聚低耦合，通常选择简化减少交互，以及增加中间层实现两方隔离。MQ 就是其中的中间层，引入 MQ 后生产者和消费者不必知道彼此的存在也不必同时在线。

**削峰填谷**

由于业务特性，系统闲忙分布不均，QPS 时常相差几十倍甚至更高。特别是交易活动期间，瞬间流量很可能超过后端系统承载能力。这就要需要通过消息中间件来缓冲，MQ 客户端实例根据自身处理能力从 MQ 服务器拉取消息，来减轻或消除后端系统瓶颈。

**异构集成**

在机构或企业信息化建设过程中，不同供应商、不同团队的产品因为封闭架构无法对外提供服务或缺少核心开发，造成彼此集成困难。通过引入 MQ 可以解决部分问题。

**异步隔离**

为了提供金融服务整体弹性，需要隔离内部、外部系统间的依赖。如支付通知分为两种，一种是同步通知，这时 API 调用会因为网络故障而超时，因为服务提供方处理能力限制而得不到及时响应等多种因素影响，另一种是异步通知，在一定时效范围内最终通知到即可，从而提供提高最终用户的体验和交易成功率，提高业务的整体生产率。

## 如何进行选型？

### 关键需求因素

**集群支持：** 为了保证消息中间件可靠性，需要提供完备的生产者、消费者、消息中间件集群方案；

**持久化的支持：** 为了避免消息丢失，需要支持消息保存到磁盘文件或其它格式存储；

**消息重试的支持：** 消息处理失败后的支持失败转存或重试，并提供消息至少投第一次或消息最多投递一次的配置；

**分布式事务的支持：** 为了保证业务完整性，选择的中间件需要支持分布式；

**消息的按序消费：** 部分场景下，需要消息的消费能够按照发送的同样顺序进行处理从而保证顺序执行；

**消息的延时支持：** 在 2C 业务处理或三方数据源对接中，会遇到消息延时投递要求，需要支持延投递；

**消息堆积和回溯功能：** 在消息中间件持久化保存大量消息时不会对性能有大的影响，支持消息查询、重发，或按照时间点来重新消费消息，以应对某段时间消息的重新消费场景。

### 次要考虑因素

**产品匹配性：** 产品与当前技术栈是否匹配，团队人员熟悉源代码更便于对消息中间件原理理解和后续功能扩展；

**产品使用广度：** 同业因为业务同质化校对，场景需求相近，使用机构、团队越多，说明关键场景支持较好，问题暴露的越充分，当实际使用时碰到问题，容易找到解决方案或解决人员；

**产品高可用性：** 金融机构需要服务持续可用，作为提高企业弹性的基础组件，集群和高可用是必不可少的；

**产品的稳定性：** 产品可以持续、稳定提供服务，不需经常因为资源泄露或性能衰减等问题而重新启动。

**产品的活跃度：** 通过 github 统计数据能看出来这个产品是否经常有人维护，经常有人开发新功能及修补 bug。

### 选型要点及原则

1、搜寻满足关键需求的框架到候选清单；

2、从功能和非功能性需求等几个方面对候选框架进行筛选；

3、在选型过程中要做好量化记录，避免先有倾向性的结果，后有筛选；

4、有时要换个角度思考，常用来做比较的可能就是最好的，如很多 MQ 框架都与 Kafka 做比较，那么 Kafka 有可能就是最通用的框架，如果做选型就要对其是否满足自己的需求做重点分析；

5、遵循第三眼美女原则，让理性引导感性；适合的就是最好的，不要但纯追求高性能和功能全面。

### 测试设计

**功能测试：** 建议搭建 POC 环境进行验证，除验证相关功能性指标有没有，还要验证好不好用。所以在测试时要基于 MQ 提供的功能构建使用场景进行业务功能实现的验证。

**性能测试：** 其实性能测试涉及的各方面因素比较多，如：基于什么样的环境，做了哪些配置，采用什么样的压测脚本和报文来做压力测试？

比较指标：

-   除 TPS *（发送者 TPS、消费者最终处理业务的 TPS）* 、
-   延时、
-   支持多少同时在线链接 *（生产者数据量、消费者数据量）* 、
-   Topic 配置 *（Topic 数量以及每个Topic 队列数量与生产者、消费者数据量的关系）* 、
-   服务器的性能指标 *（cpu、内存、磁盘 io、网络 io）* 如何等都是需要考量的。

**疲劳测试：** 在一定压力下持续运行 24 小时、一周或更长时间。要重点关注稳定性、服务器的各项指标、是否有缓慢增长的趋势等。

**重启或故障演练：** 分别对注册中心 NameServer、Broker、Producer、Consumer 的实例进行部分重启 *（或直接 kill）* 或全部重启 *（或直接 kill）* 、磁盘故障、网络故障等，查看应用的影响，如：在 RocketMQ 服务是否可以恢复，生产者消费者是否可以恢复服务，消息是否有丢失，消息是否有重复等。

以上就是金融行业进行消息队列进行选型时的一些关注点与思考方向。

**想了解不同行业**

**更多最佳实践与探索分享**

**不妨立即报名 RocketMQ Summit！**

RocketMQ Summit  作为 Apache RocketMQ 中文社区举办的官方技术大会，通过参与本大会不仅可以了解到 RocketMQ 中文社区最新动态及发展计划，还可以了解到国内外一线企业、厂商围绕 RocketMQ 生态所进行的探索欲生产实践经验，是 RocketMQ 开发者和使用者不可错过的盛会。

在诸多合作伙伴的协助以及技术贡献者的支持下，首届 RocketMQ Summit 将于 2022 年 3 月 26 - 27 日举办。26日为线下活动于北京金茂万丽酒店举办，27日为线上活动。

光大银行、中国移动、小米、闪送、中通快速、钉钉、同程艺龙、华为云等不同行业知名企业的众多技术专家带来更多场景探索与经验总结，帮助更多开发者了解Apache RocketMQ，落地Apache RocketMQ！

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/436eb6ff5cab46648217e037a79e5ef5~tplv-k3u1fbpfcp-zoom-1.image)

ITPub博客

峰会报名｜从金融行业技术选型，看 RocketMQ 如何应对严苛挑战

最新文章