面试题：消息队列在无服务器架构下如何保证消息的可靠投递

Question

在无服务器架构中使用消息队列，常常会面临函数执行环境的不确定性等问题，阐述你认为可以通过哪些机制来保证消息能够可靠地从生产者投递到消费者，并且不丢失、不重复？

Answer 1

1. 生产者端：
   • 消息持久化：将消息标记为持久化，确保在消息队列服务器重启等情况下消息不丢失。例如在RabbitMQ中，将消息的deliveryMode设置为2。
   • 确认机制：
     • 同步确认：生产者发送消息后，等待队列的确认回复，只有收到确认才认为消息发送成功。如RabbitMQ的confirm模式，生产者调用channel.confirmSelect()开启确认模式，发送消息后通过channel.waitForConfirms()等待确认。
     • 异步确认：使用异步回调的方式处理确认。以RabbitMQ为例，通过channel.addConfirmListener()添加确认监听器，在监听器中处理消息确认和未确认的情况。
2. 消息队列：
   • 持久化存储：消息队列自身采用持久化存储机制，如RabbitMQ将消息持久化到磁盘，即使服务器故障重启，也能恢复消息。
   • 集群与复制：搭建消息队列集群，通过数据复制和同步，提高消息的可用性和可靠性。例如Kafka通过多副本机制，将消息复制到多个Broker节点，保证消息不丢失。
3. 消费者端：
   • 手动确认：消费者开启手动确认模式，在成功处理消息后，向消息队列发送确认。例如在RabbitMQ中，设置autoAck为false，处理完消息后调用channel.basicAck()方法确认消息。
   • 幂等性处理：消费者实现幂等性逻辑，即多次处理相同消息的结果与处理一次相同。比如在数据库操作中，使用唯一约束或基于事务的操作，确保重复消费不产生额外影响。
4. 监控与重试：
   • 监控机制：建立对消息投递过程的监控，实时跟踪消息的发送、接收和处理状态。例如使用Prometheus等监控工具，收集消息队列相关指标，如消息堆积量、确认率等。
   • 重试机制：当消息发送或消费失败时，实现重试逻辑。可以设置固定次数重试或采用指数退避策略进行重试，如在生产者端发送消息失败时，按照一定时间间隔重试，防止瞬间大量重试造成系统压力。