java面试 - mq

RocketMq和RabbitMq的优缺点

1、RabbitMQ
优点：rabbitMq 几万级数据量，基于erlang语言开发，因此响应速度快些，并且社区活跃度比较活跃，可视化界面。
缺点：数据吞吐量相对与小一些，并且是基于erlang语言开发，比较重的问题难以维护。

2、RocketMQ
rocketMq几十万级别数据量，基于Java开发，应对了淘宝双十一考验，并且文档十分的完善，拥有一些其他消息队列不具备的高级特性。
如定时推送，其他消息队列是延迟推送，如 rabbitMq 通过设置 expire 字段设置延迟推送时间。又比如rocketmq实现分布式事务，比较可靠的。

1、如何保证系统的高可用

就rabbitMq而言，有镜像模式概念，就是用户在发送数据时候，发送到mq机器上，并且持久化磁盘，然后通过设置镜像的queue，把数的持久化地址对应表同步到另外mq机器上。这种就有效防止一台mq挂了以后，另外的mq可以直接对外提供消费功能。
就rocketMq而言，分为多主集群结构，多主多备异步复制结构，多主多备同步复制结构。

2、如何保证消息不会丢失
就rabbitmq而言，从生产者，消费者，消息队列角度分析。生产者而言，发送消息如果失败，则定义重试次数，一般设置成五次。
两种解决方式：
1、通过设置事务，进行事务回滚重试
2、通过发送者确认模式开启
方式一：channel.waitForConfirms()普通发送方确认模式；
方式二：channel.waitForConfirmsOrDie()批量确认模式；
方式三：channel.addConfirmListener()异步监听发送方确认模式；

RocketMq通过producer，broker,consumer端设置
1.Producer端：采取send()同步发送消息，发送结果是同步感知的。发送失败后可以重试，默认3次。
2.Broker端：修改刷盘策略为同步刷盘flushDiskType = SYNC_FLUSH，默认情况下是异步的。
3.Consumer端：完全消费后手动ack确认。

以下是RocketMq相关知识
RocketMq架构各个模块的功能

Producer 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
Broker，消息中转角色，负责存储消息、转发消息。在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。
Consumer 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
NameServer 担任路由消息的提供者。生产者或消费者能够通过NameServer查找各Topic相应的Broker IP列表分别进行发送消息和消费消息。nameServer由多个无状态的节点构成，节点之间无任何信息同步。

RocketMq消费模式

消费模型由Consumer决定，消费纬度为Topic
1.集群消费，一条消息只会被同Group中的Consumer消费，多个group同时消费一个Topic时，每个group都会有一个consumer消费到数据。
2.广播消费，消息对每一个consumer group下的各个consumer实例都消费一遍

RocketMq的优势：

1.吞吐量高，单机的吞吐量可达十万级。
2.可用性高
3.消息可靠性高，经过参数优化配置，消息可以做到0丢失
4.支持10亿级别的消息堆积，不会因为堆积导致性能下降
5.稳定性高,经过阿里双十一的验证

RocketMq如何保证消息不丢失

1.Producer端：采取send()同步发送消息，发送结果是同步感知的。发送失败后可以重试，默认3次。
2.Broker端：修改刷盘策略为同步刷盘flushDiskType = SYNC_FLUSH，默认情况下是异步的。
3.Consumer端：完全消费后手动ack确认。

RocketMq如何保证消息顺序消费

首先要根据业务确认是否需要保证消息顺序，如果不需要则不用管，如果需要rocketMq给我们提供了MessageQueueSelector 接口，可以自己重写里面的接口，实现自己的算法。

RocketMq消息堆积如何处理

首选确认是Producer生产的消息太多消费者consumer消费不过来还是其它情况，如果是消费者不够的话可以通过上线更多consumer来临时解决问题。
另外一种方式是新上线一台consumer把原来的Topic中的消息挪到新的Topic中，不做业务处理。

RocketMq分布式事务实现原理：

rocketMq特点之一就是支持分布式事务，分布式事务可以使用TCC(Try, Confirm, Cancel)， 2pc来解决分布式系统中消息的原子性。
rocketMq实现方式：
Half Message：预处理，当broker收到消息后，会存储到 RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中，Broker会开启一个定时任务，消费 RMQ_SYS_TRANS_HALF_TOPIC队列中的消息，每次执行任务会向Producer发送确认事务执行状态(提交，回滚，未知),如果是未知Broker会定时回调重新检查。如果超过过查询次数默认会回滚消息。也就是Producer产生的消息并未真正进入Topic的Queue，而是用了临时queue来存放所谓的half message，等事务提交后才真正的将half message转移到topic下的queue。

详情以及实现方式见： https://blog.csdn.net/qq_42877546/article/details/125404307?spm=1001.2014.3001.5502

RocketMq部署方式，一般选择后两种

1.单个Master
单机模式，即只有一个Broker，如果Broker宕机了会导致mq服务不可用。
2.多Master
组成一个集群，集群没个节点都是Master节点，配置简单，性能也是最高的，某个节点宕机重启不会影响mq服务。
缺点：如果某个节点宕机了，会导致该节点存在未被消费的消息，在节点恢复之前不能被消费。
3.多Master多Slave模式，异步复制
每个Master配置一个Slave，多对Master-Slave，Master与Slave消息采用异步复制
优点：Master宕机后消费者可以从Slave节点进行消费，采用异步模式复制提升了一定的吞吐量。
缺点：如果Master宕机，如果磁盘损坏没有及时将消息复制到Slave会导致少量消息丢失。
4.多Master多Slave模式，同步双写
Master与Slave采用同步方式复制消息，只有master和slave都写入成功后才会向客户端返回成功
优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性和数据可用性非常高
缺点：会降低消息写入效率，影响吞吐量