MQ常见的问题

yYahoo～

于 2023-07-30 23:36:31 发布

阅读量2k

点赞数

分类专栏： Java 文章标签： java

本文链接：https://blog.csdn.net/Yangyeon_/article/details/132013472

版权

Java 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

如何避免消息堆积问题。

消息堆积：
生产者的生产速率远远大于消费者的消费速率，使消息大批量的堆积在消息队列

解决方案：

1. 提升消费者的消费速率（增加消费者集群）

2. 消费者分批多线程去处理

3. 限流，保证进入到消息队列的都是有用的消息

如何避免重复消费问题

产生原因：

1. 生产者产生了两条一模一样的消息。

2. 消费者一条消息消费了多遍

消息重试：消息重试一般发生于一个消费者发生了异常（网络波动或者系统假死），这个时候消费者就会通知生产者重新发送，带来重复消费的问题。

可以采用常用的幂等解决方案（分布式锁），全局id+业务场景保证唯一性。所有的重复提交问题，都可以用幂等性来解决。

为了保险起见，也可以在数据库上做好唯一索引。

如何保证消息不丢失

1. 消息确认机制，生产者必须确认消息成功刷盘到硬盘中，才确认消息发送成功。

acks 参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入是成功的。这个参数对消息丢失的可能性有重要影响。

该参数有如下选项：

如果 acks=0 ，生产者在成功写入消息之前不会等待任何来自服务器的响应。也就是说，如果当中出现了问题，导致服务器没有收到消息，那么生产者就无从得知，消息也就丢失了。不过，因为生产者不需要等待服务器的响应，所以它可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。
如果 acks=1 ，只要集群的Leader节点收到消息，生产者就会收到一个来自服务器的成功响应。如果消息无法到达Leader节点（比如Leader节点崩溃，新的Leader还没有被选举出来），生产者会收到一个错误响应，为了避免数据丢失，生产者会重发消息。不过，如果一个没有收到消息的节点成为新Leader，消息还是会丢失。这个时候的吞吐量取决于使用的是同步发送还是异步发送。如果让发送客户端等待服务器的响应（通过调用 Future 对象的 get() 方法），显然会增加延迟（在网络上传输一个来回的延迟）。如果客户端使用回调，延迟问题就可以得到缓解，不过吞吐量还是会受发送中消息数量的限制（比如，生产者在收到服务器响应之前可以发送多少个消息）。
如果 acks=-1(或all)，只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。这种模式是最安全的，它可以保证不止一个服务器收到消息，就算有服务器发生崩溃，整个集群仍然可以运行。不过，它的延迟比 acks=1 时更高，因为要等待不只一个服务器节点接收消息。

2. 消息持久化机制，作为mq中间件，会把消息持久化到硬盘

3. 消费者必须确认消息消费成功，否则进行重试，重试达到一定次数后，通知开发人员做好补偿措施。

关闭自动提交。当消费者完成消费后，再手动提交，防止mq的自动提交。当消费者接收到消息后，mq以为消费者已经消费了，但如果这个时候消费者挂了，这条消息就没有被消费。