前言：公司要把ActiveMQ全部下架全换成RocetMQ了，正巧我负责的项目有部分用到了RocketMQ，所以来学习一下
参考：
https://yq.aliyun.com/articles/66129?spm=5176.100240.searchblog.73.utoU93
https://www.jianshu.com/p/824066d70da8
https://www.jianshu.com/p/2838890f3284
https://blog.csdn.net/qq_34462387/article/details/86562856
https://blog.csdn.net/zhangcongyi420/article/details/90548393
目录
第一章 RocketMQ由来
1.1 来源
阿里巴巴消息中间件起源于2001年的五彩石项目，Notify在这期间应运而生，用于交易核心消息的流转。
至2010年，B2B开始大规模使用ActiveMQ作为消息内核，随着阿里业务的快速发展，急需一款支持顺序消息，拥有海量消息堆积能力的消息中间件，MetaQ 1.0在2011年诞生。
到2012年，MetaQ已经发展到了MetaQ 3.0，并抽象出了通用的消息引擎RocketMQ。随后，将RocketMQ进行了开源，阿里的消息中间件正式走入了公众的视野。
到2015年，RocketMQ已经经历了多年双十一的洗礼，在可用性、可靠性以及稳定性等方面都有出色的表现。与此同时，云计算大行其道，阿里消息中间件基于RocketMQ推出了Aliware MQ 1.0，开始为阿里云上成千上万家企业提供消息服务。
到2016年，MetaQ在2016年双十一承载了万亿级消息的流转，跨越了一个新的里程碑，同时RocketMQ进入Apache 孵化。
第二章 RocketMQ原理
2.1 基本概念
Producer：消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。
Producer Group：生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。
Consumer：消息消费者，简单来说，消费 MQ 上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。
Consumer Group：消费者组，和生产者类似，消费同一类消息的多个 consumer 实例组成一个消费者组。
Topic：Topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。
Message：Message 是消息的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。也可以添加额外的键值对，例如你需要一个业务 key 来查找 broker 上的消息，方便在开发过程中诊断问题。
Tag：标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
Broker：Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。
Name Server：Name Server 为 producer 和 consumer 提供路由信息。
2.2 运作原理
注：
长与短连接：数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。
1) Name Server
Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
2) Broker
Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的Broker Name，不同的Broker Id来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
每个Broker与Name Server集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。
3) Producer
Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
Producer每隔30s（由ClientConfig的pollNameServerInterval）从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。
Producer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。
4) Consumer
Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。
Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。
当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失。但是一旦master恢复，未同步过去的消息会被最终消费掉。
总结：
Broker会定时注册topic到Name Server上，Producer与Consumer会定时从Name Server上读取Topic信息。
Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。
Broker每隔10s扫描所有存活的Producer连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。
Broker每隔10s扫描所有存活的Consumer连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。
2.3 消息模型
2.3.1 广播消费
一条消息被多个 Consumer 消费，即使这些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每个 Consumer 都消费一次，广播消费中的 Consumer Group 概念可以认为在消息划分方面无意义。
类似于ActiveMQ中的发布订阅模式
2.3.2 集群消费
一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个 Consumer Group 有 3 个实例(可能是 3 个进程，或者 3 台机器)，那么每个实例只消费其中的 3 条消息。
类似于ActiveMQ中的虚拟主题模式
注：RocketMQ不遵循JMS规范，有一套自定义的机制，它不存在点对点和发布订阅模式的区别，简单的说，RMQ都是使用订阅主题的方式去发送和接收消息的，支持的消费模型有下面2种： 集群模式：消费端设置消费模式为MessageModel.CLUSTERING，这种方式就可以达到水平扩展负载均衡消费消息 广播模式：消费端设置消费模式MessageModel.BROADCASTING这种模式下，就是相当于生产者端发送消息到RMQ，多个消费者端可以同时获得消息消息，顾名思义广播模式
2.3.3 pull和push
在RocketMQ中一般有两种获取消息的方式，一个是拉(pull，消费者主动去broker拉取)，一个是推(push，主动推送给消费者)
push：
实时性高，但增加服务端负载，消费端能力不同，如果push的速度过快，消费端会出现很多问题
消费者从server端拉消息，主动权在消费端，可控性好，但是时间间隔不好设置，间隔太短，则空请求会多，浪费资源，间隔太长，则消息不能及时处理
原理：
push方式里，consumer把轮询过程封装了，并注册MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送过来的。
pull方式里，取消息的过程需要用户自己写，首先通过打算消费的Topic拿到MessageQueue的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量取消息，一次取完后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue。
第三章 RocketMQ与ActiveMQ对比
因为之前只用过ActiveMQ所以就只和ActiveMQ对比一下了，貌似RocketMQ完全吊打ActiveMQ。。
第四章 RocketMQ的作用
4.1 异步处理
以用户注册，并且需要注册邮件和短信为例。用户注册后，需要发送注册邮件和注册短信。传统的做法有两种：串行和并行方式。如下图所示：
引入消息队列后：
4.2 应用解耦
用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：
传统模式的缺点：
1）假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。
2）订单系统与库存系统耦合
引入消息队列后：
1）订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
2）库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。
4.3 流量削峰
流量削峰也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。
秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，需要在应用前端加入消息队列。
1）可以控制活动的人数。
2）可以缓解短时间内高流量压垮应用。
1）用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
2）秒杀业务根据消息队列中的请求信息，再做后续处理。
4.4 事务处理
注：这个还不大清楚，大概抄一下，回头去看一下数据库事务一致性和分布式系统数据、分布式事务消息一致性再来详细说一下，参考：https://www.jianshu.com/p/2838890f3284。
比如银行转账。
如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认，钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败 。
1364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
