RocketMQ

RocketMQ是一个开源的分布式消息中间件，它提供了可靠的消息传递和高吞吐量的分布式消息发布/订阅服务。它支持消息的可靠性投递，并具有低延迟和高并发处理能力。RocketMQ使用了主题（Topic）和标签（Tag）的概念来进行消息的分发。 

主题（Topic）是消息的逻辑分类，可以将一类相关的消息归为同一个主题。生产者（Producer）将消息发送到特定的主题，而消费者（Consumer）则可以订阅感兴趣的主题来接收消息。

标签（Tag）是对主题的进一步细分，可以用于在主题下对消息进行过滤。消费者可以根据标签来选择性地接收消息，以满足不同的业务需求。

RocketMQ具有灵活的消息分发机制，可以根据主题和标签来实现不同的消息路由策略。这样，消息可以根据不同的条件被分发到不同的消费者进行处理，实现了灵活的消息分发和消费。

总结来说，RocketMQ通过主题和标签的概念来实现消息的分发。生产者将消息发送到特定的主题，消费者可以根据主题和标签来选择性地接收消息。这样，RocketMQ可以实现灵活的消息分发和高吞吐量的消息处理能力。

1.应用场景

1.业务（异步）解耦

 如果没有RocketMQ，那么通过OpenFegin是同步调用的，有了RocketMQ是异步调用的，此时第一次请求返回的不是真实数据，但做出响应后，用户被更快的释放，可以继续操作，第二次返回的是真实的结果。这样做可能会导致获取真实结果的时间更长，但用户操作的僵直时间会变短，用户体验会更好。

2.削峰填谷

         以12306为例，假设平时可能买票的人不多，所以订单系统的QPS也不是很高，每秒也就处理1000个请求，此时突然并发达到每秒3000，而订单系统每秒最大处理1000并发，可能出现宕机，可以设计高可用的RocketMQ，让所有的请求都打到MQ，缓存起来。这样一来高峰期的流量和数据都将积压在MQ中，流量高峰就被削弱了（削峰），避免高并发的请求，可以从MQ中拉去自己能力范围内的消息进行处理，这样突发产生的积压的消息也被消费完了，就叫填谷。

3.消息分发

rocketMq有集群模式和广播模式的区别，且rocketMq默认为集群模式 

集群模式和广播模式的区别：

        （1）集群模式：同一个consumerGroupName下的多个consumer平摊消息队列中的消息，例如三个消费者处于同一个group下，且订阅了同一个topic，加入生产者往消息队列中放入了这个topic的6条消息，那么消费者消费消息的总和为6条，消费完的消息不能被其他实例所消费；
        （2）广播模式：指的是consumer属于同一个ConsumerGroup,消息也会被ConsumerGroup中的每个Consumer都消费一次，广播消费中ConsumerGroup概念可以认为在消息划分方面无意义

2.不同消息中间件对比

 RocketMQ和RabbitMQ不能共存，和KafKa可以共存

         MQ首先是一个集群，有一个消息，从生产者发送到MQ,同步刷盘（在返回应用写成功状态前，消息已经被写入磁盘）指的是消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，给应用返回消息写成功的状态。异步刷盘指的是消息发送到MQ后，被写入内存的PAGECACHE后，立即返回写成功给生产者端，然后另一个异步线程专门会将PageCache中的数据写到磁盘里，确保消息的持久化。

        顺序消费

         定时消息：生产者将一条消息发送到消息队列后并不期望这条消息马上会被消费者消费到，而是期望到了指定的时间，消费者才可以消费到。

        延迟消息其实是对于定时消息的另外一种解释，指的是生产者期望消息延迟一定时间，消费者才可以消费到。可以理解为定时到当前时间加上一定的延迟时间。

        事务消息：指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。

        消息重试和死信队列

        当消息转移到死信队列中后，处在死信队列中的消息，不能推送给消费者，但可以被消费，可以写一个死信队列的消费者，把死信队列中的信息存储到表中，可以通过前端（人工客服）做处理。当自动消费的没有实现，就走人工。

        当消费者消费的次数很多时，会实现幂等性。通过redis的setnx（分布式锁的方式），zookeeper（分布式锁的方式）、文本文件（分布式锁的方式）、mysql加日志等。

RocketMQ发送流程和消费流程

RocketMQ内部主要name server 名称服务和broker server 代理服务组成

name server 主要存储元数据，包括brokername,url,topic,queue...

broker server 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。

topic  表示一类消息的集合，每个主题包含4条消息队列（默认），每条消息队列只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

两者之间通过心跳（服务的同步）来维持信息的准确性。

生产的过程：

生产者小组，包含多个生产者，每个生产者，要指定name server、指定tpoic、准备消息message、发送消息，生产者先访问name server，根据tpoic查询broker server 相关的元数据，如果没找到，返回null，如果找到了，返回这个元数据给生产者，然后生产者根据返回的元数据，访问对应的broker server，如果元数据为null，表示时第一次访问，那么就会在broker server中创建一个topic，这个topic默认有四个消息队列，把message随机（负载均衡）放到某一个队列中，然后把这个元数据同步到name server中（通过心跳）。如果元数据不是null，那么根据元数据的topic，把message随机（负载均衡）放到某一个队列中，然后把这个元数据同步到name server中（通过心跳）。

消费的过程：

消费者小组有多个，每个消费者小组又包含多个消费者，存储广播和集群的；消费者指定name server，指定topic，监听这个topic，接受message，返回给MQ一个ack（问答值），消费者连接name server，获取元数据，获取不到，等待，获取到了，返回元数据给消费者。消费者根据返回元数据监听topic，如果没有消息，进行等待（阻塞队列）；如果有消息，就消费

生产者发送的消息带tag标签，用于同一主题下区分不同类型的消息，消费者小组具有消息过滤作用，消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。