1) Name Server
Name Server是⼀个⼏乎⽆状态节点，可集群部署，节点之间⽆任何信息同步。 作用：管理集群中的元数据，查看producer、broker、consumer是否存活
2) Broker 收发消息
Broker部署相对复杂，Broker分为Master与Slave（作用：读写分离，如果读写都在master上，则master扛不住），⼀个Master可以对应多个Slave，但是⼀个Slave只
能对应⼀个Master，Master与Slave的对应关系通过指定相同的Broker id，不同的Broker Id来定
义，BrokerId为0表示Master，⾮0表示Slave。
每个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（由ClientConfifig的pollNameServerInterval）从Name server获取所有topic队列
的
最新情况，这意味着如果Broker不可⽤，Producer最多30s能够感知，在此期间内发往Broker的所有消
息都会失败。
Producer每隔30s（由ClientConfifig中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（由ClientConfifig中heartbeatBrokerInterval决定）向所有关联的broker发送⼼
跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送⼼跳数据，则关闭连接；并向该
Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。
当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来
了，因此会有少量的消息丢失。但是⼀旦master恢复，未同步过去的消息会被最终消费掉。
顺序消费 1.严格实现顺序消费，简单可⾏的办法就是： 保证 ⽣产者—MQServer—消费者 是“⼀对⼀对⼀”的关系。 注意 这样的设计⽅案问题： 1.并⾏度会成为消息系统的瓶颈（吞吐量不够） 2.产⽣更多的异常处理。⽐如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的 精 ⼒来解决阻塞的问题。 2.通过合理的设计保证局部有序： 从业务层⾯来保证消息的顺序，⽽不仅仅是依赖于消息系统 最后从源码⻆度分析RocketMQ怎么实现发送顺序消息。 RocketMQ通过轮询所有队列的⽅式来确定消息被发送到哪⼀个队列（负载均衡策略）。 ⽐如下⾯的
在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择⼀个队列，同⼀个OrderId 获取到的肯定是同⼀个队列。
消息重复 造成消息重复的根本原因是：⽹络不可达。 只要通过⽹络交换数据，就⽆法避免这个问题。所以解决这个问题的办法是绕过这个问题。 那么问题就变成了：如果消费端收到两条⼀样的消息，应该怎样处理？ 1.消费端处理消息的业务逻辑要保持幂等性。 2.保证每条数据都有唯⼀编号，且保证消息处理成功与去重表的⽇志同时出现。 事务消息 RocketMQ⽀持事务消息，下⾯来看看RocketMQ是怎样来实现发送事务消息的： rocketMQ分三个阶段： 第⼀阶段发送Prepared消息时，会拿到消息的地址。 第⼆阶段执⾏本地事务。 第三阶段通过第⼀阶段拿到的地址去访问消息，并修改消息的状态。
消费失败：
消费方由于网络延迟导致ack未返回或没有接收到消息，失败可以
1.人工处理
2.绕过mq，在消费端接收来自生产者的接口，开一个定时任务，轮询所有的订单id，和已经消费的数据做一个对比
Producer如何发送消息 Producer轮询某Topic下所有队列的⽅式来实现发送⽅的负载均衡，如下图所示：
RocketMQ的客户端发送消息的源码：
消息存储 RocketMQ的消息存储是由comsume queue 和 cimmit log配合完成的。 consume queue是消息的逻辑队列，相当于字典的⽬录，⽤来指定消息在物理⽂件commit log上的位 置。 CommitLog 要想知道RocketMQ如何存储消息，我们先看看CommitLog。在RocketMQ中，所有topic的消息都存储 在⼀个称为CommitLog的⽂件中，该⽂件默认最⼤为1GB，超过1GB后会轮到下⼀个CommitLog⽂ 件。通过CommitLog，RocketMQ将所有消息存储在⼀起，以顺序IO的⽅式写⼊磁盘，充分利⽤了磁盘 顺序写减少了IO争⽤提⾼数据存储的性能， 消息在CommitLog中的存储格式如下:
ConsumeQueue ⼀个ConsumeQueue表示⼀个topic的⼀个queue，类似于kafka的⼀个partition，但是rocketmq在消 息存储上与kafka有着⾮常⼤的不同，RocketMQ的ConsumeQueue中不存储具体的消息，具体的消息 由CommitLog存储，ConsumeQueue中只存储路由到该queue中的消息在CommitLog中的offffset， 消息的⼤⼩以及消息所属的tag的hash（tagCode），⼀共只占20个字节，整个数据包如下：
消息存储⽅式 前⽂已经描述过，RocketMQ的消息存储由CommitLog和ConsumeQueue两部分组成，其中 CommitLog⽤于存储原始的消息，⽽ConsumeQueue⽤于存储投递到某⼀个queue中的消息的位置信 息，消息的存储如下图所示：
消费者在读取消息时，先读取ConsumeQueue，再通过ConsumeQueue中的位置信息读取 CommitLog，得到原始的消息。 消息订阅 RocketMQ消息订阅有两种模式： ⼀种是push模式，即MQServer主动向消费端推送。 另⼀种是Pull模式，即消费端在需要时，主动到MQServer拉取。 但是再具体实现时，Push和Pull模式都是采⽤消费端主动拉取的⽅式。 ⾸先看下消费端的负载均衡
消费端会通过RebalanceService线程，10s做⼀次基于Topic下的所有队列负载： 1.遍历Consumer下所有的Topic，然后根据Topic订阅所有的消息 2.获取同⼀Topic和Consume Group下的所有Consumer 3.然后根据具体的分配策略来分配消费队列，分配的策略包含：平均分配、消费端配置等 如上图所示，如果有5个队列，2个Consumer，那么第⼀个Consumer消费3个队列，第⼆个Consumer 消费2个队列。这⾥采⽤的就是平均分配策略。它类似于分⻚的过程，Topic下⾯所有的Queue就是记 录，Consumer的个数就相当于总的⻚数，那么每⻚有多少条记录，就类似于Consumer会消费哪些队 列。 通过这样的策略来达到⼤体上的平均消费，这样的设计也可以很⽅便地⽔平扩展来提⾼Consumer的消 费能⼒。 消费端的Push模式是通过⻓轮询的模式来实现的，就如同下图：（Pull模式示意图）
Consumer端每隔⼀段时间主动向broker发送拉消息请求，broker在收到Pull请求后，如果有消息就⽴ 即返回数据，Consumer端收到返回的消息后，再回调消费者设置的Listener⽅法。如果broker在收到 Pull请求时，消息队列⾥没有数据，broker端会阻塞请求直到有数据传递或超时才返回。 RocketMQ的最佳实践 Producer最佳最佳实践 1.遍历Consumer下所有的Topic，然后根据Topic订阅所有的消息 2.获取同⼀Topic和Consume Group下的所有Consumer 3.然后根据具体的分配策略来分配消费队列，分配的策略包含：平均分配、消费端配置等1.⼀个应⽤尽可能⽤⼀个Topic，消息⼦类型⽤tags来标识，tags可以由应⽤⾃由设置。只有发送 消息设 置了tags，消费⽅在订阅消息时，才可以利⽤tags在broker做消息过滤。 2.每个消息在业务层⾯的唯⼀标识码，要设置到keys字段，⽅便将来定位消息丢失问题。 3.消息发送成功或者失败，要打印消息⽇志，务必打印sendResult和key字段 4.对于消息不可丢失应⽤，务必要有消息重发机制。例如：消息发送失败，存储到数据库，能有定 时程 序尝试重发或者⼈⼯触发重发。 5.某些应⽤如果不关注消息是否发送成功，请直接使⽤sendOneWay⽅法发送消息。 Consumer最佳实践 1.消费过程要做到幂等 2.尽量使⽤批量⽅式消费，可以很⼤程度上提⾼消费吞吐量。 3.优化每条消息的消费过程 其他配置 线上应该关闭autoCreateTopicEnable，即在配置⽂件中将其设置为false。 RocketMQ在发送消息时，会⾸先获取路由信息。如果是新的消息，由于MQServer上⾯还没有创建对 应的Topic，这个时候，如果上⾯的配置打开的话（autoCreateTopicEnable=true），会返回默认Topic 的路由信息（RocketMQ会在每台Broker上⾯创建名为TBW102的Topic），然后Producer会选择⼀台 Broker发送消息，选中的Broker在存储消息时，发现消息的Topic还没有创建，就会⾃动创建Topic。后 果就是：以后所有该Topic的消息，都将发送到这台Broker上，达不到负载均衡的⽬的。 所以基于⽬前RocketMQ的设计，建议关闭⾃动创建Topic的功能，然后根据消息量的⼤⼩，⼿动创建 Topic
------------恢复内容开始------------
1.MQ背景&选型 消息队列作为⾼并发系统的核⼼组件之⼀，能够帮助业务系统解构提升开发效率和系统稳定性。主要具 有以下优势： 削峰填⾕（主要解决瞬时写压⼒⼤于应⽤服务能⼒导致消息丢失、系统奔溃等问题） 系统解耦（解决不同重要程度、不同能⼒级别系统之间依赖导致⼀死全死） 提升性能（当存在⼀对多调⽤时，可以发⼀条消息给消息系统，让消息系统通知相关系统,把非关键业务剥离主流程，比如把邮件短信业务与订单、库存的主业务分开） 蓄流压测（线上有些链路不好压测，可以通过堆积⼀定量消息再放开来压测） ⽬前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相⽐于Rabbitmq、kafka具有主要优 势特性有： • ⽀持事务型消息（消息发送和DB操作保持两⽅的最终⼀致性，rabbitmq和kafka不⽀持） • ⽀持结合rocketmq的多个系统之间数据最终⼀致性（多⽅事务，⼆⽅事务是前提） • ⽀持延迟消息（rabbitmq和kafka不⽀持） • ⽀持指定次数和时间间隔的失败消息重发（kafka不⽀持，rabbitmq需要⼿动确认） • ⽀持consumer端tag过滤，减少不必要的⽹络传输（rabbitmq和kafka不⽀持） • ⽀持重复消费（rabbitmq不⽀持，kafka⽀持）
1) Name Server
Name Server是⼀个⼏乎⽆状态节点，可集群部署，节点之间⽆任何信息同步。 作用：管理集群中的元数据，查看producer、broker、consumer是否存活
2) Broker 收发消息
Broker部署相对复杂，Broker分为Master与Slave（作用：读写分离，如果读写都在master上，则master扛不住），⼀个Master可以对应多个Slave，但是⼀个Slave只
能对应⼀个Master，Master与Slave的对应关系通过指定相同的Broker id，不同的Broker Id来定
义，BrokerId为0表示Master，⾮0表示Slave。
每个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（由ClientConfifig的pollNameServerInterval）从Name server获取所有topic队列
的
最新情况，这意味着如果Broker不可⽤，Producer最多30s能够感知，在此期间内发往Broker的所有消
息都会失败。
Producer每隔30s（由ClientConfifig中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（由ClientConfifig中heartbeatBrokerInterval决定）向所有关联的broker发送⼼
跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送⼼跳数据，则关闭连接；并向该
Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。
当Consumer得到master宕机通知后，转向slave消费，slave不能保证master的消息100%都同步过来
了，因此会有少量的消息丢失。但是⼀旦master恢复，未同步过去的消息会被最终消费掉。
顺序消费 1.严格实现顺序消费，简单可⾏的办法就是： 保证 ⽣产者—MQServer—消费者 是“⼀对⼀对⼀”的关系。 注意 这样的设计⽅案问题： 1.并⾏度会成为消息系统的瓶颈（吞吐量不够） 2.产⽣更多的异常处理。⽐如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的 精 ⼒来解决阻塞的问题。 2.通过合理的设计保证局部有序： 从业务层⾯来保证消息的顺序，⽽不仅仅是依赖于消息系统 最后从源码⻆度分析RocketMQ怎么实现发送顺序消息。 RocketMQ通过轮询所有队列的⽅式来确定消息被发送到哪⼀个队列（负载均衡策略）。 ⽐如下⾯的
在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择⼀个队列，同⼀个OrderId 获取到的肯定是同⼀个队列。
消息重复 造成消息重复的根本原因是：⽹络不可达。 只要通过⽹络交换数据，就⽆法避免这个问题。所以解决这个问题的办法是绕过这个问题。 那么问题就变成了：如果消费端收到两条⼀样的消息，应该怎样处理？ 1.消费端处理消息的业务逻辑要保持幂等性。 2.保证每条数据都有唯⼀编号，且保证消息处理成功与去重表的⽇志同时出现。 事务消息 RocketMQ⽀持事务消息，下⾯来看看RocketMQ是怎样来实现发送事务消息的： rocketMQ分三个阶段： 第⼀阶段发送Prepared消息时，会拿到消息的地址。 第⼆阶段执⾏本地事务。 第三阶段通过第⼀阶段拿到的地址去访问消息，并修改消息的状态。
消费失败：
消费方由于网络延迟导致ack未返回或没有接收到消息，失败可以
1.人工处理
2.绕过mq，在消费端接收来自生产者的接口，开一个定时任务，轮询所有的订单id，和已经消费的数据做一个对比
Producer如何发送消息 Producer轮询某Topic下所有队列的⽅式来实现发送⽅的负载均衡，如下图所示：
RocketMQ的客户端发送消息的源码：
消息存储 RocketMQ的消息存储是由comsume queue 和 cimmit log配合完成的。 consume queue是消息的逻辑队列，相当于字典的⽬录，⽤来指定消息在物理⽂件commit log上的位 置。 CommitLog 要想知道RocketMQ如何存储消息，我们先看看CommitLog。在RocketMQ中，所有topic的消息都存储 在⼀个称为CommitLog的⽂件中，该⽂件默认最⼤为1GB，超过1GB后会轮到下⼀个CommitLog⽂ 件。通过CommitLog，RocketMQ将所有消息存储在⼀起，以顺序IO的⽅式写⼊磁盘，充分利⽤了磁盘 顺序写减少了IO争⽤提⾼数据存储的性能， 消息在CommitLog中的存储格式如下:
ConsumeQueue ⼀个ConsumeQueue表示⼀个topic的⼀个queue，类似于kafka的⼀个partition，但是rocketmq在消 息存储上与kafka有着⾮常⼤的不同，RocketMQ的ConsumeQueue中不存储具体的消息，具体的消息 由CommitLog存储，ConsumeQueue中只存储路由到该queue中的消息在CommitLog中的offffset， 消息的⼤⼩以及消息所属的tag的hash（tagCode），⼀共只占20个字节，整个数据包如下：
消息存储⽅式 前⽂已经描述过，RocketMQ的消息存储由CommitLog和ConsumeQueue两部分组成，其中 CommitLog⽤于存储原始的消息，⽽ConsumeQueue⽤于存储投递到某⼀个queue中的消息的位置信 息，消息的存储如下图所示：
消费者在读取消息时，先读取ConsumeQueue，再通过ConsumeQueue中的位置信息读取 CommitLog，得到原始的消息。 消息订阅 RocketMQ消息订阅有两种模式： ⼀种是push模式，即MQServer主动向消费端推送。 另⼀种是Pull模式，即消费端在需要时，主动到MQServer拉取。 但是再具体实现时，Push和Pull模式都是采⽤消费端主动拉取的⽅式。 ⾸先看下消费端的负载均衡
消费端会通过RebalanceService线程，10s做⼀次基于Topic下的所有队列负载： 1.遍历Consumer下所有的Topic，然后根据Topic订阅所有的消息 2.获取同⼀Topic和Consume Group下的所有Consumer 3.然后根据具体的分配策略来分配消费队列，分配的策略包含：平均分配、消费端配置等 如上图所示，如果有5个队列，2个Consumer，那么第⼀个Consumer消费3个队列，第⼆个Consumer 消费2个队列。这⾥采⽤的就是平均分配策略。它类似于分⻚的过程，Topic下⾯所有的Queue就是记 录，Consumer的个数就相当于总的⻚数，那么每⻚有多少条记录，就类似于Consumer会消费哪些队 列。 通过这样的策略来达到⼤体上的平均消费，这样的设计也可以很⽅便地⽔平扩展来提⾼Consumer的消 费能⼒。 消费端的Push模式是通过⻓轮询的模式来实现的，就如同下图：（Pull模式示意图）
Consumer端每隔⼀段时间主动向broker发送拉消息请求，broker在收到Pull请求后，如果有消息就⽴ 即返回数据，Consumer端收到返回的消息后，再回调消费者设置的Listener⽅法。如果broker在收到 Pull请求时，消息队列⾥没有数据，broker端会阻塞请求直到有数据传递或超时才返回。 RocketMQ的最佳实践 Producer最佳最佳实践 1.遍历Consumer下所有的Topic，然后根据Topic订阅所有的消息 2.获取同⼀Topic和Consume Group下的所有Consumer 3.然后根据具体的分配策略来分配消费队列，分配的策略包含：平均分配、消费端配置等1.⼀个应⽤尽可能⽤⼀个Topic，消息⼦类型⽤tags来标识，tags可以由应⽤⾃由设置。只有发送 消息设 置了tags，消费⽅在订阅消息时，才可以利⽤tags在broker做消息过滤。 2.每个消息在业务层⾯的唯⼀标识码，要设置到keys字段，⽅便将来定位消息丢失问题。 3.消息发送成功或者失败，要打印消息⽇志，务必打印sendResult和key字段 4.对于消息不可丢失应⽤，务必要有消息重发机制。例如：消息发送失败，存储到数据库，能有定 时程 序尝试重发或者⼈⼯触发重发。 5.某些应⽤如果不关注消息是否发送成功，请直接使⽤sendOneWay⽅法发送消息。 Consumer最佳实践 1.消费过程要做到幂等 2.尽量使⽤批量⽅式消费，可以很⼤程度上提⾼消费吞吐量。 3.优化每条消息的消费过程 其他配置 线上应该关闭autoCreateTopicEnable，即在配置⽂件中将其设置为false。 RocketMQ在发送消息时，会⾸先获取路由信息。如果是新的消息，由于MQServer上⾯还没有创建对 应的Topic，这个时候，如果上⾯的配置打开的话（autoCreateTopicEnable=true），会返回默认Topic 的路由信息（RocketMQ会在每台Broker上⾯创建名为TBW102的Topic），然后Producer会选择⼀台 Broker发送消息，选中的Broker在存储消息时，发现消息的Topic还没有创建，就会⾃动创建Topic。后 果就是：以后所有该Topic的消息，都将发送到这台Broker上，达不到负载均衡的⽬的。 所以基于⽬前RocketMQ的设计，建议关闭⾃动创建Topic的功能，然后根据消息量的⼤⼩，⼿动创建 Topic
------------恢复内容结束------------