MQ的了解

MQ的了解：

如果进行产品选型

Kafka

优点：吞吐量非常大，性能非常好，集群高可用。

缺点：会丢数据，功能比较单一

使用场景：日志分析、大数据采集
RebbitMQ

优点：消息可靠性高，功能全面。

缺点：吞吐量比较低，消息积累会严重影响性能。erlang语言不好定制。

使用场景：小规模场景。

RocketMQ （阿里产品）

优点：高吞吐、高性能、高可用，功能非常全面。

缺点：开源版功能不如云上商业版。官方文档和周边生态还不够成熟。客户端只支持java
使用场景：几乎是全场景。

rabbitmq的镜像队列原理(需要集群)

如何保证消息的顺序？

全局有序和局部有序：MQ只需要保证局部有序，不需要保证全局有序。
生产者把一组有序的消息放到同一个队列当中，而消费者一次消费整个队列当中的消息。
RocketMQ中有完整的设计，但是在RabbitMQ和Kafka当中，并没有完整的设计，需要自己进行设计。
RabbitMQ：要保证目标exchange只对应一个队列。并且一个队列只对应一个消费者。
Kafka：生产者通过定制partition分配规则，将消息分配到同—个partition。Topic下只对应一个消费者。

rabbitmq的死信队列、延迟队列原理

延迟队列可以说是死信交换机+ttl
死信消息：

1.消息被消费方否定确认，使用 channel.basicNack 或 channel.basicReject，并且此时 requeue 属性被 设置为false。
2. 消息在队列的存活时间超过设置的TTL时间。
3. 3. 消息队列的消息数量已经超过最大队列长度。 那么该消息将成为死信消息。如果配置了死信队列信息，那么该消息将会被丢进死信队列中，如果没有配置，则该 消息将会被丢弃

为每个需要使用死信的业务队列配置一个死信交换机，同一个项目的死信交换机可以共用一个，然后为每个业务队 列分配一个单独的routeKey，死信队列只不过是绑定在死信交换机上的队列，死信交换机也不是什么特殊的交换 机，只不过是用来接受死信的交换机，所以可以为任何类型 【Direct. Fanout. Topic]

TTL：一条消息或者该队列中的所有消息的最大存活时间

如果一条消息设置了TL属性或者进入了设置TTL属性的队列，那么这条消息如果在TTL设置的时间内没有被消费， 则会成为”死信”。如果同时配置了队列的TTL和消息的TTL，那么较小的那个值将会被使用。 只需要消费者一直消费死信队列里的消息

rabbitmq可以直连队列么？

生产者和消费者使用相同的参数声明队列。重复声明不会改变队列

RabbitMQ如何保证消息的可靠性传输
1、使用事务消息
2、使用消息确认机制

发送方确认：

channel设置为confirm模式，则每条消息会被分配一个唯一id
消息投递成功，信道会发送ack给生产者，包含了id，回调ConfirmCallback接口
如果发生错误导致消息丢失，发生nack给生产者。回调ReturnCallback接口
ack和nack只有一个触发，且只有一次，异步触发。可以继续发送消息

接收方确认：

声明队列时，指定noack=false， broker会等待消费者手动返回ack、才会删除消息，否则立刻删除
broker的ack没有超时机制，只会判断链接是否断开，如果断开、消息会被重新发送

RabbitMQ如何确保消息发送？消息接收？(异步)

发送方确认机制：

信道需要设置为 confirm 模式，则所有在信道上发布的消息都会分配一个唯一ID。

一旦消息被投递到queue（可持久化的消息需要写入磁盘），信道会发送一个确认给生产者（包含消息唯一ID).

如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条 nack（未确认）消息给生产者。

所有被发送的消息都将被 confirm（即 ack) 或者被nack一次。但是没有对消息被 confirm 的快慢做任何保证，并 且同一条消息不会既被 confirm又被nack

发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以维绩发送消息。当确认消息到达生产者，生产者的回调 方法会被触发。

Confirmcallback接口：只确认是香正确到达 Exchange 中，成功到达则回调 Returncallback接口：消息失败返回时回调

接收方确认机制：

消费者在声明队列时，可以指定noAck参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号后才从内存 （或者磁盘，持久化消息中移去消息。香则， 消息被消费后会被立即删除。

消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitmQ 才能安全地把消思从队列中删除。

RabbitMQ不会为未ack的消息设買超时时间，它判断此消,息是香需要重新投递给消费者的唯一依据是消费该消息的消费者 连接是否已经断开。这么设计的原因是RabbitwQ允许消费者消效一条消忌的时间可以很长。保证数据的最终一致性：
如果消费者返回ack之前街开了链接，RabbitwQ 会重新分发给下一个订阅的消费者。〈可能存在消息重复消费的的惠， 需要去重）
可以key为唯一id 存储reids中
(确保数据的一直 ,限流) tcp长链接

RabbitMQ事务消息

RabbitMQ事务消息

通过对信道的设置实现

1. channel.txSelect0；通知服务器开启事务模式；服务端会返回Tx.Select-ok
2. channel.basicPublish；发送消息，可以是多条，可以是消费消息提交ack
3. 3. channel.txCommit0提交事务；
4. channel.txRollbacko回滚事务；

消费者使用事务：

1. autoAck=false，手动提交ack，以事务提交或回滚为准；
2. autoAck=true，不支持事务的，也就是说你即使在收到消息之后在回滚事务也是于事无补的，队列已经把消 息移除了

如果其中任意一个环节出现问题，就会拋出loException异常，用户可以拦截异常进行事务回滚，或决定要不要重 复消息。

事务消息会降低rabbitmq的性能(事务消息会发送到临时队列中)

RocketMQ 如何保证不丢消息

生产者：

同步阻塞的方式发送消息，加上失败重试机制，可能broker存储失败，可以通过查询确认 • 异步发送需要重写回调方法，检查发送结果_ ack机制，可能仔储COrTTTictug，存储ConsumerQueue失败，此时对消费者不可见

broker：同步刷盘、集群模式下采用同步复制、会等待slave复制完成才会返回确认

消费者：

offset手动提交，消息消费保证幂等