MQ常见的问题(kafka保证消息不丢失)

MQ常见的问题

1,mq如何避免消息堆积问题。

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

解决方案:1,提升消费者的消费速率(增加消费者集群)

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

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

2,如何避免重复消费问题

产生原因: 1,生产者产生了两条一模一样的消息。

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

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

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

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

3,如何保证消息不丢失

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

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

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

结合具体的业务场景来进行选择。

2,消息持久化机制,作为mq中间件,会把消息持久化到硬盘,因为内存里的数据断电就丢失了

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

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

4,如何保证消费的顺序一致性

大多数的项目不需要保证顺序一致性,某些特殊场景必须保证顺序一致性,比如说,mq用于保证redis和mysql的数据一致性。

绑定同一个消费队列,消费的时候进行要注意如果使用了多线程处理,避免重新创建list,要在原来的list进行修改。

5,mq怎么用于保证redis和数据库的数据一致性

1,当执行update后,发送mq去通知消费者更新redis数据

优点:解耦,提高接口响应速度,有相应的补偿策略

缺点:延迟比较高

2,监听binlog日志,结合mq,去更新redis(canal实现)

优点:更加解耦

缺点:延迟更高

3,双删策略

6,消费者怎么知道mq里有消息了

两种方案:

1,mq主动通知(push)

当mq中有消息,就会通知消费者来进行消费。这种模型有一个致命伤,就是慢消费。

2,消费者轮询(pull)

消费者去轮询看看有没有自己要消费的消息。这种模型也有弊端就是消息延迟与忙等。

如果消费者的速度比发送者的速度慢很多,势必造成消息在mq的堆积。假设这些消息都是有用的无法丢弃的,消息就要一直在mq端保存。当然这还不是最致命的,最致命的是mq给消费者推送一堆无法处理的消息,消费者不是拒绝就是报错,然后来回踢皮球。

反观pull模式,消费者可以按需消费,不用担心自己处理不了的消息来骚扰自己,而mq堆积消息也会相对简单,无需记录每一个要发送消息的状态,只需要维护所有消息的队列和偏移量就可以了。所以消息量有限且到来的速度不均匀的情况,pull模式比较合适。

由于主动权在消费方,消费方无法准确地决定何时去拉取最新的消息。如果一次pull取到消息了还可以继续去pull,如果没有pull取到则需要等待一段时间重新pull。

但等待多久就很难判定了。当然也不是说延迟就没有解决方案了,业界较成熟的做法是从短时间开始(不会对mq有太大负担),然后指数级增长等待。比如开始等5ms,然后10ms,然后20ms,然后40ms……直到有消息到来,然后再回到5ms。

即使这样,依然存在延迟问题:假设40ms到80ms之间的50ms消息到来,消息就延迟了30ms,而且对于半个小时来一次的消息,这些开销就是白白浪费的。

在阿里的RocketMq里,有一种优化的做法-长轮询,来平衡推拉模型各自的缺点。基本思路是:消费者如果尝试拉取失败,不是直接返回,而是把连接挂在那里等待,服务端如果有新的消息到来,把连接复用起来,这也是不错的思路。但海量的长连接mq对系统的开销还是不容小觑的,还是要合理的评估时间间隔。

7,如果mq宕机后,生产者怎么处理。

生产者在向mq投递消息的时候,可以将要投递的消息记录下来(可以在数据库中插入一条数据,也可以输出相应的日志记录)后期可以编写定时任务,定期向mq发送之前发送不成功的消息。

8,mq的消费策略

集群消费:同一个消费者集群,只能消费一条消息,但是一条消息可以被多个消费者集群消费。

广播消费:通知集群中的所有节点都进行消费(涉及到数据分片处理的场景),对数据不敏感 的场景可以采用普通hash,对数据敏感的场景可以采用hash环。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值