RocketMQ分布式消息中间件(核心原理与最佳实践)

第9章RocketMQ企业*佳实践 前面几章介绍了RocketMQ各个组件的功能和基本原理，本章主要介绍RocketMQ如何在企业落地，主要内容如下： l RocketMQ集群管理。 l RocketMQ集群监控和报警。 l RocketMQ集群测试环境实践。 l Spring和Python如何接入RocketMQ？ 9.1 RocketMQ落地概述 9.1.1 为什么选择RocketMQ 一款技术产品要在企业落地是非常困难的，笔者总结了几个要点，供读者在选择一款技术产品时参考：稳定可靠、运维与管理方便、低成本、性能考量。 接下来，我们对消息队列中间件的选型做详细分析。 业务需求永远是**需求。对业务而言，组件能够稳定、可靠、可持续地保障业务正常流转肯定是首要的需求。在经历过阿里巴巴、VIPKID、蚂蚁金服、微众银行等对于稳定性有极致需求的大厂洗礼后，稳定、可靠成为了RocketMQ的代言词。 作为技术人员，一款产品的管理、运维和开发的难易程度也是选型的重要参考指标。现代互联网公司不同于传统企业，快速迭代、快速把握市场才是王道。简单、方便的产品能快速支持业务起步，对开发者友好的或者自研的产品总是容易掌控，也能快速适应业务的发展和变化。 RocketMQ使用Java语言开发，做二次开发或集成到现有系统难度较低。RocketMQ社区也相当活跃，文档包含中英文，对国内开发者非常友好。同时，社区提供的管理平台功能完善，更新也比较活跃，RocketMQ的衍生产品也非常丰富，比如rocketmq-connect-es、rocketmq-flink、rocketmq-hbase等。 成本，对于商业公司是必须要考虑的。这里的成本包含硬成本和软成本，如图9-1所示。 下面，我们介绍一下硬成本。服务器成本：技术产品都需要部署在硬件服务器上才能提供服务，硬件包含内存、CPU、磁盘等耗材，配置越高花费越大。 软件授权成本：对开源产品而言，虽然企业付出的金钱成本为0，更多的却是责任。RocketMQ在阿里巴巴内部从一个普通技术项目到一个可靠的、可用的技术项目经历了11年（从2001年到2012年），从一个技术项目再到技术产品经历了4年（从2012年到2016年），从阿里巴巴走向Apache的开源之路又经历了4年（从2016年到现在2020年），总共经历了19年，阿里巴巴和社区的付出有多少我们难以想象。作为一个普通的技术从业者，“拿来主义”不提倡，投桃报李方可行。 对于软成本，笔者觉得比硬成本更重要，因为它是看不见的，往往被大家忽略。可能很多人追求技术的创新却忘记了软成本，导致留下无数的技术债，随着业务不断发展，技术壁垒也愈发明显。 *后一个重要的考虑：性能。2020年互联网行业仍然是流量的行业，高并发、大吞吐是当前面临的*大挑战之一。RocketMQ在阿里巴巴内部各个平台都广泛使用，并且成功支撑了多个双11万亿级别的消息流量，充分证明了RocketMQ强大的吞吐能力。 9.1.2 如何做RocketMQ的集群管理 RocketMQ的集群管理主要是对集群中Broker、Namesrv、Topic、生产者、消费者进行统一管控。 RocketMQ本身提供了一系列的管理接口，具体实现在org.apache.rocketmq.tools.admin. DefaultMQAdminExt.java文件中，源代码结构如图9-2所示。 一般在生成环境中严禁开放自动创建Topic和消费者组，需要通过API进行统一管理。下面简单列出了4.2.0版本支持的一些管理API，如表9-1所示，供大家在自研治理系统时参考。当然原生工具也提供命令行管理。 表9-1的大部分核心功能在社区提供的RocketMQ-Console管理平台中都有，笔者建议使用RocketMQ-Console或者像VIPKID一样自研一套管理平台替代命令行操作，这样更加安全可靠。如何搭建RocketMQ-Console在4.2.2节中有详细的描述，读者可以按照描述一步步操作搭建。 在VIPKID，我们基于RocketMQ开发了VKMQ（VIPKID消息队列），包含Broker、 Namesrv、游乐场管理平台、基于Prometheus的监控报警模块（Prometheus Exporter代码已经贡献给Apache社区，可以直接下载使用）等整套生态，负责中国、美国等世界几十个国家和地区之间的消息扭转，目前的生产环境已稳定地运行了两年多。 在VIPKID，*重要的不是知道如何管理集群，而是要知道在管理方法后面的每一个操作都需要有Double-Check。 接下来，笔者将基于社区版RocketMQ Console讲解企业在践行RocketMQ时遇到的问题较多的场景。 9.2 RocketMQ集群管理 9.2.1 Topic管理 Topic管理是集群管理中常见的操作，包括创建Topic、查看Topic路由、修改Topic配置、重置消费位点。 1．创建Topic 创建Topic的核心在于，你需要知道Topic和队列（Queue）的关系，也叫Topic路由分布，下面展示一个名为topicA的Topic路由关系，如图9-3所示。 如图9-3所示，topicA有4个Queue，分布在两台Broker上。当有消息发送的时候，默认会均匀地发送给这4个Queue。 接下来我们看看如何在RocketMQ Console上创建topicA。 我们进入Topic管理页面，单击“新增/更新”按钮，会出现如图9-4所示的弹窗。 下面将依次讲解每个输入框的含义。 集群名：RocketMQ集群名，和下一个选项BROKER_NAME二者选其一，如果选择集群名，则表示这个新建Topic的Queue会分布在这个集群的全部Broker中。 BROKER_NAME：RocketMQ Broker的名字，选择后新建Topic的Queue会分布在选中的Broker机器上。集群名和BROKER_NAME只需选择一个就可以。 主题名：Topic名字，字符串长度不能超过255，不能与系统默认名字冲突，还需要满足正则表达式：^[%|a-zA-Z0-9_-]+$。 读/写队列数量：每台Broker上Queue的数量，建议设置为相同值。 perm：Topic权限，这是一个常量，该常量的定义在org.apache.rocketmq.common. constant.PermName类中。2表示只写，4表示只读，6表示读写均可。 创建完成后，检查创建的Topic是否和我们预期的一致。刷新页面后，搜索刚刚创建的topicA，单击“路由信息”按钮，可以看到topicA的路由信息如图9-5所示。 更新Topic在实际业务场景中会经常用到，我们通过两个场景进行具体的讲解。 场景1：Topic扩容 如果在实际业务中发现当前的发送效率已经不能满足业务需求，那么扩容是一种常用的处理手段。如图9-3所示，接受topicA消息的全部压力都在master broker 1和master broker 2上，我们怎样才能用新机器分摊压力呢？ **步：部署新的master broker 3、master broker 4机器，部署步骤详见4.2.2节。 第二步：回到RocketMQ Console平台的Topic管理页面，单击“新增/更新”按钮。 第三步：如图9-4所示，在BROKER_NAME输入框中选择新加的Broker。在输入Queue数量时要注意读、写Queue的数值表示在单台Broker中的数量，如果想将一半的流量分流到新的Broker中，那么读、写Queue数量都填2。扩容后topicA的发送效率将增加一倍，新旧2组机器压力承担比例为1:1，扩容后topicA的路由图变成如图9-6所示的样子。 场景2：Topic权限更改 如图9-6所示，如果扩容后Master Broker 4机器有问题，那么理论上topicA会有1/4的消息发送失败，此时可以更改topicA在Master Broker 4上的权限为0，表示不可读、不可写，如图9-7所示。 我们稍加分析可知，master broker 4在禁止读写后，topicA的路由会改变，全部的生产者在感知到路由变化后，不再将消息发送到master broker 4。 消费者在进行Rebalance后，也会感知topicA的路由发生变化，将不再从master broker 4拉取消息消费。