1. 如何防止消息丢失
- 发送方：ack是1或-1/all可以防止消息丢失，如果要做到99.9999%，ack=all，把min.insync.replicas配置成分区备份数
- 消费方：自动提交改为手动提交
2. 如何防止消息的重复消费
一条消息被消费者消费多次，。如果为了消息的不重复消费，而把生产端的重试机制关闭，消费端的手动提交改为自动提交，这样反而会出现消息丢失。那么可以直接在防止消息丢失的手段上加上消费消息时的幂等性特保证，便能解决重复消费的问题。
幂等性如何保证：
- MySQL插入业务id作为主键，主键是唯一的，所以一次只能插入一条
- 使用Redis或zk的分布式锁（主流解决方案）
3.如何做到顺序消费
- 发送方：在发送时将ack不能设置为0，关闭重试。使用同步发送，等到发送成功再发送下一条，确保消息时顺序发送的。
- 接收方：消息时发送到一个分区中，只能有一个消费者组的消费者接收消息。
kafka的顺序消费会牺牲部分性能。
4.解决消息积压问题
消息积压会导致很多问题，比如：磁盘被打满、生产端发消息导致kafka性能过慢，就容易出现服务雪崩，就需要相应的处理手段。
- 方案一：在一个消费者中启动多个线程，让多个线程同时消费。提升一个消费者的消费能力。
- 方案二：如果方案一还不够的话，这时候可以启动多个消费者，多个消费者部署到不同的机器上。其实，多个消费者部署在同一服务器上也可以提高消费能力，充分利用服务器的CPU资源。
- 方案三：让一个消费者去把收到的消息往另外一个topic上发，另一个topic设置多个分区和多个消费者，进行具体的业务消费。
5.延迟队列
延迟队列的应用场景：在订单创建成功后如果超过30分钟没有付款，则需要取消订单，此时用延时队列来创建
-
创建多个topic，每个topic表示延时的间隔
- topic_5s:延时5s执行的队列
- topic_1m:延时1分钟执行的队列
- topic_30m：延时30分钟执行的队列
-
消息发送者发送消息到相应的topic，并带上消息的发送时间
-
消费者订阅相应的topic，消费时轮询消费整个topic中的消息