【后端开发面试题】每日 3 题（二十）

✍个人博客：Pandaconda-CSDN博客
📣专栏地址：https://blog.csdn.net/newin2020/category_12903849.html
📚专栏简介：在这个专栏中，我将会分享后端开发面试中常见的面试题给大家，每天的题目都是独立且随机的，之前的面试题不会影响接下来的学习~
❤️如果有收获的话，欢迎点赞👍收藏📁，您的支持就是我创作的最大动力💪

题目 1: 什么是分布式一致性？常见的分布式一致性算法有哪些？

答案：
分布式一致性是指在分布式系统中，多个节点之间如何保持数据的一致性。由于网络延迟、节点故障等问题，实现一致性是一个复杂的挑战。

常见的分布式一致性算法：

1. Paxos

   • 特点：一种经典的分布式一致性算法，通过多轮投票机制达成共识。
   • 优点：理论基础扎实，适合强一致性场景。
   • 缺点：实现复杂，难以理解和调试。

2. Raft

   • 特点：比 Paxos 更易于理解，通过领导者选举、日志复制和安全性保证一致性。
   • 优点：逻辑清晰，适合教学和工程实践。
   • 缺点：性能略逊于 Paxos，在极端场景下可能不够灵活。

3. ZAB (Zookeeper Atomic Broadcast)

   • 特点：Zookeeper 使用的协议，支持顺序性和原子性广播。
   • 优点：专为 Zookeeper 设计，性能稳定。
   • 缺点：与 Zookeeper 深度绑定，适用范围有限。

4. Gossip 协议

   • 特点：基于流言传播的方式同步数据，适用于大规模分布式系统。
   • 优点：去中心化，扩展性强。
   • 缺点：最终一致性，无法保证强一致性。

5. Quorum（多数派协议）

   • 特点：通过写入和读取的多数派机制保证一致性。
   • 优点：简单高效，适合分布式存储系统。
   • 缺点：对网络分区敏感。

总结：

• 对于强一致性要求高的场景，选择 Paxos 或 Raft。
• 对于大规模弱一致性场景，选择 Gossip 协议或 Quorum。

---

题目 2: 如何设计一个高可用的消息队列系统？请描述核心组件和实现思路。

答案：
消息队列系统用于解耦生产者和消费者，提升系统的可靠性和扩展性。以下是设计高可用消息队列系统的核心组件和实现思路：

核心组件：

1. 消息存储

   • 使用持久化存储（如 Kafka 的分区日志、RabbitMQ 的队列）确保消息不会丢失。
   • 支持多副本机制（如 Leader-Follower）提高可靠性。

2. 消息分发

   • 实现负载均衡策略（如轮询、随机分配），将消息均匀分发到消费者。
   • 支持批量消费和异步处理，提升吞吐量。

3. 高可用性

   • 使用主从复制或多活架构避免单点故障。
   • 支持故障检测和自动切换。

4. 监控与报警

   • 监控消息堆积、延迟和消费速率等指标。
   • 在异常情况下触发报警通知。

5. 扩展性

   • 支持动态扩容和缩容，适应流量变化。

实现思路：

1. 选择合适的消息队列工具

   • 根据需求选择 Kafka（高吞吐量）、RabbitMQ（灵活性强）或 RocketMQ（事务支持）。

2. 设计分区与副本

   • 将消息分散到多个分区，每个分区有多副本以提高可靠性。

3. 实现消息确认机制

   • 消费者在成功处理消息后发送 ACK，确保消息不会重复消费或丢失。

4. 优化性能

   • 批量发送和消费消息，减少网络开销。
   • 使用压缩算法（如 Snappy、Gzip）降低存储成本。

5. 处理消息积压

   • 设置合理的 TTL（生存时间），自动清理过期消息。
   • 增加消费者实例，提升消费能力。

示例：
以下是一个简单的高可用消息队列架构：

• 使用 Kafka Cluster 实现分区和多副本存储。
• 使用 Zookeeper 管理集群元数据和故障切换。

---

题目 3: 什么是服务限流与熔断？它们的区别是什么？如何实现服务限流与熔断？

答案：
服务限流和服务熔断是微服务架构中常用的容错机制，用于保护系统的稳定性和可用性。

服务限流：

• 定义：限制请求的速率或并发数，防止系统过载。
• 作用：保护下游服务，避免因流量过大导致崩溃。
• 实现方式：
  • 使用令牌桶算法或漏桶算法控制请求速率。
  • 示例：每秒最多允许 100 次请求。

服务熔断：

• 定义：当某个服务出现故障或响应时间过长时，快速失败并返回错误信息。
• 作用：防止雪崩效应，保护下游服务。
• 实现方式：
  • 使用熔断器模式（如 Hystrix、Resilience4j）。
  • 定义熔断阈值（如连续失败次数）和恢复时间窗口。

区别：

特性	服务限流	服务熔断
触发条件	流量过大或超出设定阈值	服务不可用或响应超时
目标	控制请求速率，保护系统稳定性	快速失败，防止级联故障
实现方式	限制请求速率或并发数	拦截请求并返回错误信息

示例：

• 限流：API 网关限制每秒最多 50 次请求，超出部分返回 429 错误。
• 熔断：支付服务不可用时，直接返回错误信息，避免用户等待。