RocketMQ基础介绍

1.RocketMQ功能介绍

    消息队列是一种“先进先出”的数据结构，分布式消息队列的作用：①应用解耦。②消息分发。③流量削峰。   

2.RocketMQ各部分角色介绍

4个角色：producer，consumer, broker, nameserver

    一个Topic可以设置一个或者多个Message Queue, Message Queue类似于分区或partition。

    两台机器启动多个NameServer和Broker：在两台机器上分别启动NameServer，在每台机器上分别启动Master角色的Broker和Slave角色的Broker。两台机器上一共启动4个Broker。

启动单机RocketMQ，只需启动NameServer和Broker：

    启动NameServer：

    nohup sh bin/mqnameser & tail -f ~/Logs/rocketmqLogs/nameser.log

    启动Broker：

    nohup sh bin/mqbroker -n localhost:9876 & tail -f ~/Logs/rocketmqLogs/broker.Log

    关闭NameServer：

    sh bin/mqshutdown broker  

    sh bin/mqshutdown nameserv

3.发送和接收消息的流程

    创建一个DefaultMQProducer对象，设置好GroupName和NameServer地址后启动，把消息封装成Message对象，使用Producer来发送。

    Consumer和Producer都必须指定GroupName，NameServer地址端口号。

    创建topic：updateTopic

    删除topic：deleteTopic

    创建/修改订阅组updataSubGroup：同一个组里的消费者共同消费一个topic里面的内容。

    删除订阅组deleteSubGroup

    查看topic列表信息TopicList：列出集群中所有topic名称。

    查看topic统计信息TopicStats：查看topic的状态，看看有多少消息的数量，有多少未处理

    根据时间查询消息printMsg

    根据ID查询某一条消息queryMsgByID

    查看哪些Broker在提供服务clusterList

4.用合适的方式接收和发送消息

    根据使用者对读取操作的控制作用，消费者可以分为两种类型：一是DefaultMQPushConsumer，系统控制读取操作，收到消息后自动调用方法来处理消息。二是DefaultMQPullConsumer，读取操作中大部分功能由使用者自己控制。

    DefaultMQPushConsumer主要是设置好各种参数和处理消息的函数，系统收到消息后自动调用函数来处理消息，自动保存offset。需要设置3个参数：一是这个consumer的GroupName，二是NameServer的地址和端口号，三是Topic的名称。

    Consumer的GroupName把多个Consumer组织到一起，提高并发处理能力，GroupName需要和消息模式配合使用。

    RocketMQ支持两种消息模式：Cluster和Broadcast

cluster模式下，同一个ConsumerGroup中的每一个consumer消费topic的一部分内容，所有的consumer消费合起来才是一个topic的整体。

broadcast模式下，同一个ConsumerGroup中的每一个Consumer都消费了整个topic，一个消息会被多次分发。

    如果不需要消费某个topic下的所有消息，可以根据消息的Tag对消息做选择性消费。Tag的参数可以为“null”或者“ * ”。

    消费消息有两种方式：push和pull

    Push方式是Server接收到消息后，主动把消息推送到Client端。

    Pull方式是Client端主动从Server拉取消息。

    读取某个Topic下所有Message Queue的内容：

①获取Message Queue并遍历：一个topic下有多个Message Queue，可以遍历全部，也可以选择性遍历

②维护offset：拉取消息时要传入参数offset，不断读取消息，offset会变长，由用户存储起来

    自定义消息发送规则：可以使用MessageQueueSelector来将消息发送到指定的MessageQueue中

    RocketMQ的事务支持：事务就是一系列原子性的操作要同时成功活同时失败。首先将待确认的消息持久化，然后等待消息发送发的业务处理的结果，若成功则将持久化的消息标记为可投递，接收方会接收到消息。若失败，则将持久化的消息删除，接收方不会接收到消息。

    存储队列位置信息：Offset的含义是某个topic下的某条消息在Message Queue中的位置。在使用DefaultMQPushConsumer时不用关心Offset。但是使用DefaultMQPullConsumer时，就要自己处理Offset，将Offset存储起来。

5.分布式消息队列的协调者

    NameServer的功能：它是整个消息队列中的状态服务器，集群中各个组件信息的汇总。RocketMQ不需要zookeeper，它只需要一个轻量级的元数据服务。

    NameServer在集群中扮演调度中心的角色，各个producer和Consumer上报自己的状态，同时NameServer获取其他角色的状态信息。

    ConsumerQueue类似索引，指向真正数据的地址，commitLog才是真正的物理存储。

    Broker可以接受Producer的写和Consumer的读，Slave只可以接受Consumer的读。

6.消息处理

    全局顺序消息：

    在默认情况下，一个Topic有8个读队列和8个写队列，消息被哪个consumer消费是不确定的。如果要保证全局顺序消息，那么将Topic的读写队列都设置为1，producer和consumer的并发也设置为1。

    部分顺序消息：

    发送方：将同一业务ID的消息，发送到同一个MessageQueue中

    消费方：读取MessageQueue中的消息不做并发处理

    关于消息重复问题，RocketMQ的消息处理方式是，确保一定会投递，可能会出现重复消息。

    1.保证消费逻辑幂等性

    2.给每条消息都设置一个唯一的ID，将消费后的消息ID存入一张表中，当新的消息ID和表中的ID相同，则说明此消息已经被消费过，就不再处理这条消息。

    最好的做法还是业务端去重。

    消费的优先级：①创建多个topic②将消息写入同一个Topic的不同的MessageQueue中

    吞吐量优先的使用场景，对消息进行过滤：

    ①consumer根据每条数据的Tag进行过滤

    ②用命令行方式对消息的key进行过滤

    ③自定义上传到broker的java类来进行过滤

    提高Consumer的消费能力：

    ①提高消费并行度：

       1.加机器

       2.启动多个consumer进程，启动的consumer进程不能多于MessageQueue的个数，不然剩余的consumer无法消费到消息

     ②批量消费，设置consumer的消息块的大小