kafka、RocketMq、Rabbitmq大对比image.pngimage.png

Producer：消息的发送者；举例：发信者
Consumer：消息接收者；举例：收信者
Broker：暂存和传输消息；举例：邮局
NameServer：管理Broker；举例：各个邮局的管理机构
Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者
可以订阅一个或者多个Topic消息
Message Queue：相当于是Topic的分区；用于并行发送和接收消息

Rocketmq的流程

1、name server集群先启动，并记录Producer集群、Broker里面有什么主题信息、Consumer集群信息，起到一个控制中心的作用，也有点类似于路由的作用；zookpeer功能太多了，这里只需要一个控制中心的作用
2、Broker再启动，并将ip等信息注册到Name Server中;broker作为消息的处理，比如存储消息、事务消息的回查；
3、Producer产生消息，怎么找Broker呢？先去Name Server中找Broker信息，然后与Broker建立连接，并向Broker发送数据
4、Consumer消费消息，怎么找Broker呢？也是先去Name Server中找Broker信息，然后与Broker建立连接，并从Broker拉取数据。当然也能推送消息到Consumer
———————————————————————————————————————————————————————————
1. nameserver:这里类似注册中心，各个nameserver数据不需要同步，是无状态的。
2. Broker：启动broker后就会与nameserver创建一个长连接将自己的信息通过心跳包的方式发送给集群中每一个nameserver服务(所以nameserver之间不需要数据的同步)。BrokerId为0的是master，非0则是slaver，主从关系的绑定是通过brokerName去实现的。只有brokerId=1的slave可以进行读服务。其他只是用来进行高可用的
3. Producer:producer服务启动后与nameserver创建长连接，定期从nameserver中获取对应topic的信息，然后producer与broker中的master节点创建长连接，进行心跳检测
4. Consumer：从nameserver中知道自己订阅的topic是哪个broker，然后进行消费
———————————————————————————————————————————————————————————
image.png
image.png
image.png
image.png
image.png
image.png
topic是指定的，Broker和Queue是随机的，一个broker里面可以有多个不同的topic，一个topic里面有多个queue，这里的queue可以分布在不同的broker上面（如果顺序消息，可以指定一个Queue,然后消息全部写入这一个Queue）
发送的消息发布到对应的topic主题下的队列里面去，是轮询式挨个存放(不指定队列的情况下)，这里的队列可以放置于不同的broker

RocketMQ顺序发送消息

image.pngimage.png

RocketMQ事务消息image.png

image.png
生产者生产消息后，发送Prepare消息，写入到HalfTopic（此时消息并不是完整的消息）,此时消费者并不能读取到这个消息（只有这个消息提交以后才能读取到）。
1、先向Broker发送预请求，预请求发送成功以后，通过回调方法，执行本地事务（例如从数据库中读取数据等），事务执行成功了，再次提交这个消息到OpTopic，提交到RealTopic，此时消费者才可见这个消息。消费端消费消息失败，有重试机制。
如果本地事务执行失败了，或者返回超时了，则比较HalfTopic与OpTopic的消息，通过回调方法，确定需要回查的消息进行事务回查
image.png

1.几种方式发送消息

同步消息：

发送消息后等待一个返回结果，否则会阻塞住。（ack确认机制）
image.png
image.png

异步消息：

image.png

设置重试次数：

image.png

发送单向消息：

image.png
image.png
单向消息直接将消息发送给本地的socket的缓冲区，然后让缓冲区去对接broker，不管后果，性能高，但不安全。日志可以这么做

订阅消息的方式有哪些？

消费者订阅消息有两种方式：push/pull
1、push：主动推送，注册messageListener,当订阅的队列里面有消息就唤醒consumeMessage()，实现消息的消费
优点：高实时性
缺点：不了解客户端的消费能力，容易压垮客户端
2、Pull:用户主动调用，获取topic的messagequeue后，进行轮询，批量取信息，一次取完后标记偏移量，作为下次获取信息的开始。取完再换另外一个messagequeue

消息发送中状态的详细讲解：（同步的时候才有这些状态）

  1. send_ok:当启用同步服务器或者同步刷盘机制（持久化到磁盘才会返回ack确认机制），那么这个时候的ok才是表示消息是可靠的

  2. FLUSH_DISK_TIMEOUT:同步刷盘超时，消息被保存在内存中，只有当服务器宕机消息才会丢失。
    如果是同步刷盘(FlushDiskType=SYNC_FLUSH)，需要5s内完成.默认是异步刷盘

    3. FLUSH_SLAVE_TIMEOUT:消息成功，但是同步到slave超时，消息被保存在内存中，服务器宕机消息才会丢失。未在同步刷盘默认的5秒内完成了消息的同步则算超时

  3. SLAVE_NOT_AVAILABLE：消息发送成功，slave不可用

    怎么提升消息的写入性能

    image.png