如何防止消息丢失

• 生产者：
  1. 使用同步发送
  2. 把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.具体方案

1. kafka中创建相应的主题，每个topic表示延时的间隔
   • topic_5s: 延时5s执行的队列
   • topic_1m: 延时1分钟执行的队列
   • topic_30m: 延时30分钟执行的队列
2. 消息发送者发送消息到相应的topic，并带上消息的发送时间
3. 消费者订阅相应的topic，消费该主题的消息（轮询）
4. 消费者消费消息时判断消息的创建时间和当前时间是否超过30分钟（前提是订单没支付）
   • 如果是：去数据库中修改订单状态为已取消
   • 如果否：记录当前消息的offset，并不再继续消费之后的消息。等待1分钟后，再次向kafka拉取该offset及之后的消息，继续进行判断，以此反复。