共计 2780 个字符，预计需要花费 7 分钟才能阅读完成。
作者：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！
