如何防止消息丢失
- 生产者:
- 使用同步发送
- 把ack设成1或者all(非0,0可能会出现消息丢失的情况),并且设置同步的分区数>=2
- 消费者:把自动提交改成手动提交
如何防止重复消费
在防止消息丢失的方案中,如果生产者发送完消息后,因为网络抖动,没有收到ack,但实际上broker已经收到了。此时生产者会进行重试,于是broker就会收到多条相同的消息,而造成消费者的重复消费。
如何解决:
- 生产者关闭重试:虽不会发送相同消息,但会造成丢消息(不建议)【
同步发送消息并且开启重试,ack设置为1或者all
】 消费者解决非幂等性消费问题
:
所谓的幂等性:多次访问的结果是⼀样的
。对于rest的请求(get(幂等)、post(非幂等)、put(幂等)、delete(幂等))
解决方案:
- 在数据库中创建
联合主键
,防止相同的主键创建出多条记录 - 使用
分布式锁
,以业务id为锁。保证只有⼀条记录能够创建成功(setnx
)
如何做到消息的顺序消费(效率不高,RocketMQ)
- 生产者:保证消息按顺序发送,且消息不丢失——使用同步的发送,ack设置成非0的值。
- 消费者:
主题只能设置⼀个分区,消费组中只能有一个消费者
【消费者只能限制单partition顺序消费,这种效率不高】
kafka的顺序消费使用场景不多,因为牺牲掉了性能,但是比如rocketmq在这⼀块有专门的功能已设计好。
如何解决消息积压问题
积压的消息越多,消费者消费越慢(寻址越来越慢),越慢积压越多,死循环,导致整个kafka集群磁盘IO都很慢导致多个服务不可用
1.消息积压问题的出现
消费者消费消息速度远赶不上生产者生产消息的速度,导致kafka中有大量的数据没有被消费。随着没有被消费的数据堆积越多,消费者寻址的性能会越来越差,最后导致整个kafka对外提供的服务的性能很差,从而造成其他服务也访问速度变慢,造成服务雪崩。
2.消息积压的解决方案
- 消费者中,使用
多线程
,充分利用机器的性能进行消费消息。 - 通过业务的架构设计,提升业务层面消费的性能。
- 创建多个消费组,
多个消费者
,部署到其他机器上,⼀起消费,提高消费者的消费速度 - 创建⼀个消费者,该消费者在kafka另建⼀个主题,配上多个分区,多个分区再配上多个消费者。该消费者将poll下来的消息,不进行消费,直接转发到新建的主题上。此时,新的主题的多个分区的多个消费者就开始⼀起消费了。——不常用
实现延时队列的效果(实现比较费劲,RabbitMQ)
1.应用场景
订单创建后,超过30分钟没有⽀付,则需要取消订单,这种场景可以通过延时队列来实现
2.具体方案
- kafka中创建相应的主题,每个topic表示延时的间隔
- topic_5s: 延时5s执行的队列
- topic_1m: 延时1分钟执行的队列
- topic_30m: 延时30分钟执行的队列
- 消息发送者发送消息到相应的topic,并带上消息的发送时间
- 消费者订阅相应的topic,消费该主题的消息(轮询)
- 消费者消费消息时判断消息的创建时间和当前时间是否超过30分钟(前提是订单没支付)
- 如果是:去数据库中修改订单状态为已取消
- 如果否:记录当前消息的offset,并不再继续消费之后的消息。等待1分钟后,再次向kafka拉取该offset及之后的消息,继续进行判断,以此反复。