rocketmq

官网： http://rocketmq.apache.org/ 下载：选择Binary（已经编译好了的），Source是源码，需要手动编译。我用的版本是4.5.2，下载什么版本可自行选择 跳到了Apache页面，因为这个项目已经被阿里贡献给了Apache。 选择这个：下载速度快一点 下载好了之后，进入到bin目录，如果用的是window系统，只需要关心 .cmd 文件，如果是linux系统，则只需关心 .sh 文件： 有两个文件需要注意，mqnamesrv文件是用来启动Name Server的，mqbroker是启动Topic的。在启动RocketMQ服务之前，需要添加环境变量 ROCKETMQ_HOME ，value就是RocketMQ目录的路径。和 NAMESRV_ADDR ，因为是在本地运行，value就写localhost:9876就行了。还有RocketMQ是基于JAVA环境的，需要配置 JAVA_HOME ，value是jdk安装目录。 启动mqnamesrv 启动mqbroker，记得带上 -n 参数，如果报错，加载不到某某主类，那么需要在runbroker文件修改配置 启动成功 测试，发消息：.\tools.cmd org.apache.rocketmq.exampl e.quickstart.Producer 消费消息：.\tools.cmd org.apache

RocketMQ是一款开源免费的消息队列项目，由阿里开发，经受了双十一高并发大流量的考验，是一款相对成熟的产品。现已被阿里贡献给了Apache，由Apache维护。 常见的消息队列产品有ActiveMQ、RibbitMQ、RocketMQ、Kafka。 ActiveMQ是资历最老，在消息队列使用初期最多公司使用，也是最成熟的产品，但目前大多数公司因为各种原因已不再使用。 RibbitMQ开发语言是Erlang，因为会Erlang语言的人不多，所以自定义扩展性不是很好，主要由社区维护。但是它执行速度最快，使用的公司也不在少数。 RocketMQ本事就是JAVA写的，所以对于JAVA开发者来说最友好，阅读源码方便和扩展性极佳。也是基于分布式开发的，而且性能相比较来说也很快。 Kafka专注于大数据领域，在所有消息队列产品中对分布式的处理速度最快。但是它不支持消息的失败重试。 1.为什么要学习消息队列以及消息队列给我们带来了哪些好处？ 消息队列主要用来项目的解耦、削峰、异步。 解耦 ：比如现在有三个子系统都要去调用主业务系统的服务，那么主业务系统就得分别为三个子系统写相应的接口服务，而三个子系统也得写调用主业务服务的接口。 如果哪天又多加了个D系统，又或者C系统被弃用了，那么主业务又得为D系统添加相应的服务，并把C系统的服务给删掉。 这时候，系统间的服务调用就变得很繁琐了

序 本文主要研究一下rocketmq的updateTopicRouteInfoFromNameServer updateTopicRouteInfoFromNameServer rocketmq-client-4.5.2-sources.jar!/org/apache/rocketmq/client/impl/factory/MQClientInstance.java public class MQClientInstance { private final static long LOCK_TIMEOUT_MILLIS = 3000; private final InternalLogger log = ClientLogger.getLog(); private final ClientConfig clientConfig; private final int instanceIndex; private final String clientId; private final long bootTimestamp = System.currentTimeMillis(); private final ConcurrentMap<String/* group */, MQProducerInner> producerTable = new ConcurrentHashMap

序 本文主要研究一下rocketmq的updateTopicRouteInfoFromNameServer updateTopicRouteInfoFromNameServer rocketmq-client-4.5.2-sources.jar!/org/apache/rocketmq/client/impl/factory/MQClientInstance.java public class MQClientInstance { private final static long LOCK_TIMEOUT_MILLIS = 3000; private final InternalLogger log = ClientLogger.getLog(); private final ClientConfig clientConfig; private final int instanceIndex; private final String clientId; private final long bootTimestamp = System.currentTimeMillis(); private final ConcurrentMap<String/* group */, MQProducerInner> producerTable = new ConcurrentHashMap

1、导入依赖 <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>spring-boot-starter-rocketmq</artifactId> <version>1.0.0-SNAPSHOT</version> </dependency> <!-- rocketmq dependencies --> <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>4.4.0</version> </dependency> 2、配置生产者 package com.example.demo.mq; import org.apache.rocketmq.client.exception.MQClientException; import org.apache.rocketmq.client.producer.DefaultMQProducer; import org.springframework.stereotype.Component; @Component public class MyProducer { /** * 生产组，生产者必须在生产组内 */

1、现象 很多网友会问，为什么明明集群中有多台Broker服务器，autoCreateTopicEnable设置为true，表示开启Topic自动创建，但新创建的Topic的路由信息只包含在其中一台Broker服务器上，这是为什么呢？ 期望值：为了消息发送的高可用，希望新创建的Topic在集群中的每台Broker上创建对应的队列，避免Broker的单节点故障。 现象截图如下： 正如上图所示，自动创建的topicTest5的路由信息： topicTest5只在broker-a服务器上创建了队列，并没有在broker-b服务器创建队列，不符合期望。 默认读写队列的个数为4。 我们再来看一下RocketMQ默认topic的路由信息截图如下： 从图中可以默认Topic的路由信息为broker-a、broker-b上各8个队列。 2、思考 默认Topic的路由信息是如何创建的？ Topic的路由信息是存储在哪里？Nameserver？broker? RocketMQ Topic默认队列个数是多少呢？ 3、原理 3.1 RocketMQ基本路由规则 Broker在启动时向Nameserver注册存储在该服务器上的路由信息，并每隔30s向Nameserver发送心跳包，并更新路由信息。 Nameserver每隔10s扫描路由表，如果检测到Broker服务宕机，则移除对应的路由信息。

　　这次我们来说说我们的RocketMQ的安装和参数配置，先来看一下我们RocketMQ的提出和应用场景吧。 　　早在2009年，阿里巴巴的淘宝第一次提出了双11购物狂欢节，但是在2009年，服务器无法承受到大规模的并发，导致了大规模宕机停运，当时还是IOE的服务架构，也就是没有我们的消息队列中间件，直接由IBM的小型机、Oracle数据库、EMC存储设备来提供服务的，可想而知，我们的大并发场景，IOE是无法承受的，RocketMQ是由我们的国内的阿里巴巴在2010年开始由我们的阿里云的王坚博士组件团队，来处理我们的去IOE服务架构，也就产生了我们的RocketMQ中间件，经历了阿里巴巴内部的不断尝试和实践下，在2016年11月，阿里将RocketMQ捐献给Apache软件基金会，正式成为孵化项目，现在已经在我们Apache软件基金会毕业了，并且成为了Apache软件基金会的顶级项目。可想而知RocketMQ还是很成熟很可靠的。 　　说到这也就是知道了我们的RocketMQ可以于我们的消息中间件来传递我们的消息，还有很多广泛的应用场景，比如我们的异步处理事件，分布式事务协调，对于高并发的削峰平谷处理，MQ的思想还是很出众的，下面我们来先一下RocketMQ的安装吧。 安装单机（运行环境JDK版本:1.8.0_221以上） 　　1.下载。rocketmq版本:rocketmq-all

简述 分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。 例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。 解决方案 在分布式系统中，要实现分布式事务，无外乎那几种解决方案。 一、两阶段提交（2PC） 两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。 1. 运行过程 1.1 准备阶段 协调者询问参与者事务是否执行成功，参与者发回事务执行结果。 1.2 提交阶段 如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。 2. 存在的问题 2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。 2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。 2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务

1.为什么要使用消息队列 答：这个问题，咱只答三个最主要的应用场景（不可否认还有掐的，但是只答三个主要的），即以下六个字：解耦、异步、削峰 （1）解耦 传统模式： 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 （2）异步 传统模式： 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式： 中间件模式的优点： （3）削峰 传统模式： 传统模式的缺点： 并发量大的时间，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式： 中间件模式的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2.使用了消息队列会有什么缺点 答： 1.系统可用性降低：你想呀，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。 因此，系统可用性会降低 2.系统复杂性增加：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑 的东西更多，刺痛复杂性增大。 3.消息队列如何选型？ 答

这里总结一些MQ（Message Queue，消息队列）的相关知识。 消息队列的优点 解耦 在传统模式下，系统之间的耦合性太强，比如系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码。 如果将消息写入消息队列，需要消息的系统自己从消息队列中订阅，在D系统接入的时候系统A也不需要做任何修改，达到了解耦的效果。 异步 在传统模式下，一些非必要的业务逻辑以同步的方式运行，需要等待上一个业务逻辑执行完毕才能开始执行下一个业务逻辑，耗费等待的时间。 如果将消息写入消息队列，非必要的业务逻辑就可以以异步的方式运行，加快了服务响应的速度。 削峰 在传统模式下，当并发量大的时候，所有的请求都会直接怼到数据库，造成数据库连接异常，甚至宕机。 如果将消息写入消息队列，则系统A可以慢慢地按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 消息队列的缺点 我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。一个使用了MQ的项目，如果连MQ的缺点都没有考虑过，就把MQ引进去了，那就会给自己的项目带来风险。 系统可用性降低 你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，系统也就挂了。用专业的术语来解释，就是系统的可用性降低了。 系统复杂性增加