1. 说说你对 RabbitMQ 的了解？
RabbitMQ是基于AMQP协议的高性能消息队列，其核心概念包括以下五个部分：
🔹 Producer (生产者)：消息的发送者，负责将消息发送到交换器。
🔹 Queue (队列)：缓存消息的容器，存储等待被消费者处理的消息。
🔹 Exchange (交换器)：负责根据路由规则，将消息分发到一个或多个队列。
🔹 Binding (绑定)：将交换器与队列连接的规则，用于确定消息的路由方式。
🔹 Consumer (消费者)：从队列中读取消息并进行处理。
2. RabbitMQ 和 Kafka 有何区别？
🔹 设计思想：
RabbitMQ面向事务处理和实时通信。
Kafka主要用于高吞吐量的数据流处理和日志系统。
🔹 通信协议：
RabbitMQ基于AMQP协议，支持事务和复杂的消息路由。
Kafka基于自定义协议，专注于高效的数据传输。
🔹 事务支持：
RabbitMQ支持消息确认机制（ACK）和事务，保证消息可靠性。
Kafka通过分区和复制机制实现数据可靠性，但不支持AMQP风格的事务。
🔹 应用场景：
RabbitMQ适用于实时通信、任务调度、短时间延迟的场景。
Kafka适用于日志收集、流处理、大数据分析等高吞吐量的场景。
3. RabbitMQ 中什么是交换器？有哪些类型？
交换器（Exchange）是RabbitMQ中的一个核心组件，用于根据路由规则将消息分发到队列。交换器的类型决定了消息的路由方式。
交换器有以下几种类型：
🔹 Direct Exchange：
根据消息中的Routing Key（路由键）精准匹配队列。
示例：Routing Key为 error的消息只会发送到绑定了 error的队列。
🔹 Fanout Exchange：
将消息广播给所有绑定到该交换器的队列。
示例：不管Routing Key为何，消息都会分发到所有队列。
🔹 Topic Exchange：
根据Routing Key的模式匹配队列。
示例：Routing Key为 user.*的消息会发送到匹配此模式的队列。
🔹 Headers Exchange：
根据消息的Header属性来路由，而不是Routing Key。
示例：当Header中包含指定的键值对时，消息才会被路由到相应队列。
4. 怎样确保 RabbitMQ 消息不丢失？
为了确保消息不丢失，可以采取以下措施：
消息持久化：
设置队列和消息的持久化属性（durable和persistent）。
channel.queueDeclare("queue_name", true, false, false, null);
channel.basicPublish("exchange_name", "routing_key", MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());
消息确认机制（ACK）：
确保消费者处理完消息后发送ACK确认，未确认的消息会重新投递。
channel.basicAck(deliveryTag, false);
启用镜像队列（Mirrored Queue）：
在集群模式下使用镜像队列，保证队列中的消息在多个节点上有备份。
事务机制或发布确认（Publisher Confirms）：
使用事务（transaction）或发布确认（confirm）确保消息成功发送到队列。
channel.confirmSelect();
channel.basicPublish("exchange_name", "routing_key", null, message.getBytes());
if (!channel.waitForConfirms()) {
System.out.println("Message delivery failed!");
}
5. RabbitMQ 中的死信队列（DLQ）是什么？
死信队列（Dead Letter Queue）是存储无法被正常消费的消息的特殊队列。消息变成死信的几种情况：
🔹 消息被拒绝（basicReject/basicNack）并且不再重新投递。
🔹 消息在队列中存活时间超过TTL（Time-To-Live）。
🔹 队列达到最大长度，新的消息被丢弃。
配置死信队列的步骤：
🔹 定义一个普通队列并绑定到死信交换器。
🔹 设置普通队列的死信交换器和Routing Key。
Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "dlx_exchange");
args.put("x-dead-letter-routing-key", "dlx_routing_key");
channel.queueDeclare("normal_queue", true, false, false, args);
6. RabbitMQ 的消息确认机制有哪几种？
RabbitMQ提供了三种消息确认机制：
🔹 生产者确认（Publisher Confirms）：
用于确认消息是否成功到达交换器。
🔹 消费者确认（Consumer Acknowledgment）：
用于确认消息是否成功被消费者消费。
自动ACK模式：消息一旦被RabbitMQ发送到消费者，就会被标记为已消费。
手动ACK模式：需要消费者明确确认，未确认的消息会被重新投递。
🔹 事务（Transaction）：
通过事务确保消息的可靠性，但性能较低。
7. 如何实现 RabbitMQ 的延迟队列？
RabbitMQ本身不直接支持延迟队列，但可以通过TTL（消息过期时间）和死信队列实现。
实现步骤：
🔹 定义一个延迟队列，设置消息TTL和死信交换器。
🔹 消息过期后，转发到死信队列进行消费。
Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "dlx_exchange");
args.put("x-message-ttl", 60000); // 60秒
channel.queueDeclare("delay_queue", true, false, false, args);
8. RabbitMQ 的优点和缺点是什么？
优点：
🔹 支持多种协议（如AMQP、STOMP、MQTT）。
🔹 功能强大，支持事务、消息确认、路由等功能。
🔹 插件机制丰富，可扩展性强。
🔹 社区活跃，生态完善。
缺点：
🔹 性能相对较低，不适合处理高吞吐量场景。
🔹 部署和运维复杂。
🔹 对大消息（如文件、视频）的支持较弱。
9. RabbitMQ 的应用场景有哪些？
🔹 异步处理：如订单创建后异步通知用户。
🔹 流量削峰：通过队列缓解高并发场景的压力。
🔹 服务解耦：实现微服务之间的松耦合。
🔹 任务调度：如延迟任务、定时任务。
10. 如何保证RabbitMQ的高可用？
为了确保RabbitMQ的高可用性，通常需要考虑以下几个方面：
🔹 集群部署（Clustering）
将多个RabbitMQ节点配置成集群，可以提供负载均衡和故障转移的能力。在集群模式下，消息队列可以分布在多个节点上，提高系统的吞吐量。如果一个节点失败，其他节点仍然可以继续工作。
🔹 镜像队列（Mirrored Queues）
在RabbitMQ集群中，可以设置镜像队列来确保队列中的消息被复制到多个节点。如果一个节点崩溃，队列的其他副本可以接管，保证消息不丢失。这是通过设置队列的x-ha-policy参数来实现的。
🔹 持久化（Persistence）
对消息和队列进行持久化可以保护数据不会因为服务器崩溃而丢失。将消息标记为持久化（通过设置消息的delivery_mode属性为2），并确保队列也被声明为持久化，可以提高数据的可靠性。
🔹 确认和事务机制（Acknowledgments and Transactions）
使用消息确认机制可以保证消息被正确处理。消费者处理完消息后发送ack（确认）给RabbitMQ，若RabbitMQ没有收到确认，它会将消息重新分发给其他消费者。此外，RabbitMQ还支持事务性消息处理。
🔹 监控和报警（Monitoring and Alerting）
监控RabbitMQ的运行状况并设置相应的警报机制，可以及时发现并解决潜在的问题。可以利用RabbitMQ提供的管理插件来监视队列的长度、消息吞吐量和节点状态。
🔹 硬件和基础设施的冗余
在硬件层面，确保服务器、存储和网络连接的冗余可以减少单点故障的风险。使用如RAID或SAN等存储方案可以提高存储系统的可靠性。
🔹 负载均衡（Load Balancing）
使用负载均衡器可以分散到集群的连接和流量。这不仅增加了系统的吞吐量，也避免了单个节点的过载。
🔹 备份和恢复（Backup and Recovery）
定期备份RabbitMQ的状态，包括消息队列的配置和消息数据。在发生灾难性故障时，可以用备份快速恢复服务。
🔹 升级和补丁管理
定期应用RabbitMQ和操作系统的更新和补丁，可以减少因为已知安全问题或软件缺陷导致的服务中断。
🔹 故障切换（Failover）策略
为系统设计故障切换策略，以便在节点或组件失败时能够快速恢复服务。
11. 不同的MQ的对比？
🔹 ActiveMQ 老牌消息中间件，很多公司运用的很广泛，功能强大，但是互联网公司的高并发扛不住。一般在传统企业，做异步调用，系统解耦。
🔹 RocketMQ 阿里开源的，超高并发、高吞吐，性能好，基于java。
🔹 rabbitMQ 支持高并发，高吞吐，性能很高，同时有完善的后台管理界面。还支持集群化，高可用部署架构，功能完善。但是缺点是基于erlang开发，不好研究源码。
🔹 kafka功能少，优势在于专为超高吞吐量的实时日志采集，实时数据同步，实时数据计算等场景来设计。用在日志或者大数据计算方面比较多。
