doc: 1、备份文章；

docs/index.md

@@ -30,7 +30,9 @@ hero:
     - theme: alt
       text: 我的Bilibili
       link: https://space.bilibili.com/12764212
+
 ---
+
 <style>:root {
   --vp-home-hero-name-color: transparent;
   --vp-home-hero-name-background: -webkit-linear-gradient(120deg, #bd34fe 30%, #41d1ff);
@@ -51,10 +53,13 @@ hero:
   }
 }
 </style>
+
 # 欢迎来到我的博客！
+
 感谢大家一直以来的支持和关注！这个博客是基于 [VitePress](https://vitejs.cn/vitepress/) 构建的，旨在提供更高效的内容创作和管理体验。尽管我的旧博客曾承载了许多宝贵的学习记录与分享，但为了追求更好的技术体验，我决定将其迁移至新的平台。
 
 # 为什么选择迁移？
+
 随着时间的推移，我希望能在博客上进行更高效的内容创作和管理。虽然 [Hexo](https://hexo.io/zh-cn/) 是一个非常优秀的静态博客框架，提供了快速生成页面和丰富的主题支持，但在持续使用中，我遇到了以下一些问题：
 
 1. 构建速度：随着博客文章的增多，Hexo 的构建速度变慢，尤其是在多次修改和发布时，这影响了我的开发体验
@@ -64,9 +69,9 @@ hero:
 因此，我选择将博客迁移到 VitePress，一个以 Vue 3 为基础的现代文档生成器，不仅能更高效地管理内容，还能提升整体性能和可扩展性。
 
 # 访问我的旧博客
+
 如果你喜欢我的技术分享，或者希望了解更新、更丰富的内容，欢迎访问我的新博客：
 
 旧博客：[花火の红玉宫](https://01petard.github.io/)
 
 国内访问：[代码港湾](http://www.huangzexiao.top/)
-

docs/开发/My Java Guide/My Java Guide - 分布式.md

@@ -1725,7 +1725,7 @@ AMQP 消息通常包含以下几个部分：
 
 # Kafka的选择与实践
 
-基于上述分析，Kafka选择了**拉取模型**作为其核心数据传输机制。这一选择不仅符合大多数消息系统的传统设计，还特别适合于需要处理大量异构消费者的应用场景。通过实现长轮询功能，**Kafka有效地平衡了数据传输的即时性和系统的稳定性，使得即使在网络条件不稳定或消费者处理能力有限的情况下，也能保持高效的数据交换。**此外，Kafka还通过优化数据批处理和调整拉取请求的参数，进一步提高了系统的整体性能。
+基于上述推拉模式的分析，Kafka选择了**拉取模型**作为其核心数据传输机制。这一选择不仅符合大多数消息系统的传统设计，还特别适合于需要处理大量异构消费者的应用场景。通过实现长轮询功能，**Kafka有效地平衡了数据传输的即时性和系统的稳定性，使得即使在网络条件不稳定或消费者处理能力有限的情况下，也能保持高效的数据交换。**此外，Kafka还通过优化数据批处理和调整拉取请求的参数，进一步提高了系统的整体性能。
 **Kafka的拉取模型更适合数据处理场景**，因为它允许消费者根据自身处理能力自主控制数据拉取的频率和数量，有效避免了消费者过载和资源浪费。**而在业务场景中，实时性和低延迟要求更高，推送模型能更好地满足这些需求。**
 
 ## 推拉结合（Push-Pull）模式
@@ -1846,66 +1846,45 @@ AMQP 消息通常包含以下几个部分：
 
 # 高可用设计
 
-**RabbitMQ**：
-
-在生产环境下，使用集群来保证高可用性
-
-- 普通集群
+**RabbitMQ 高可用设计**
 
-  - 会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。不包含队列中的消息
-  - 当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回
-  - 队列所在节点宕机，队列中的消息就会丢失
+1. **镜像队列（Mirrored Queues）**：
+   - 在RabbitMQ中，可以通过配置镜像队列来提高系统的可用性和可靠性。当一个队列被配置为镜像队列后，该队列中的所有消息不仅会存储在主节点上，还会复制到指定数量的从节点上。这样即使主节点发生故障，从节点也可以接管消息处理工作，保证服务的连续性。
+2. **高效ACK机制**：
+   - RabbitMQ支持消息确认机制，即消费者处理完一条消息后向RabbitMQ发送ACK确认信号，只有收到ACK后，RabbitMQ才会将该消息从队列中删除。这种机制可以有效避免因消费者故障导致的消息丢失问题。同时，为了提高性能，RabbitMQ还支持批量确认和预取计数等优化手段。
+3. **集群模式**：
+   - 通过构建RabbitMQ集群，可以进一步增强系统的高可用性和伸缩性。集群中的每个节点都可以接收客户端连接，并且队列可以在多个节点之间分布，以实现负载均衡。
 
-- **镜像集群**（本质是主从模式）
+**Kafka 高可用设计**
 
-  - 交换机、队列、队列中的消息会在各个镜像节点之间同步备份。
-  - 创建队列的节点被称为该队列的主节点，备份到的其它节点叫做该队列的镜像节点。
-  - 一个队列的主节点可能是另一个队列的镜像节点
-  - 所有操作都是主节点完成，然后同步给镜像节点
-  - 主宕机后，镜像节点会替代成新的主节点
+1. **Leader-Follower机制（分区备份机制）**：
 
-- 仲裁队列（优化镜像集群）
+   Kafka中每个分区都有一个Leader副本和多个Follower副本。生产者发送的消息首先会被写入Leader副本，然后同步到所有的Follower副本。消费者只从Leader副本读取消息。如果Leader副本失效，Kafka会自动从现有的Follower副本中选举一个新的Leader。
 
-  - 与镜像队列一样，都是主从模式，支持主从数据同步
-  - 使用非常简单，没有复杂的配置
-  - 主从同步基于Raft协议，**强一致性**
-  - 代码实现：
+   一个topic有多个分区，每个分区有多个副本，其中有一个leader，其余的是follower，副本存储在不同的broker中
 
-  ```java
-  @Bean
-  public Queue quorumQueue() {
-      return QueueBuilder
-          .durable("quorum.queue") // 持久化 
-          .quorum() // 仲裁队列
-          .build();
-  }
-  ```
-
-**Kafka**：
+   所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader
 
-- 集群模式
+   <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151700526.png" alt="image-20240415170035456" style="zoom:45%;" />
 
-  - Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成
-  - 如果集群中某一台机器宕机，其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一
+2. **ISR（In-Sync Replicas）同步机制（分区副本复制机制）**：
 
-  <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151659488.png" alt="image-20240415165935408" style="zoom:45%;" />
+   ISR是指与Leader副本保持同步的所有副本集合。当Follower副本与Leader副本之间的延迟超过一定阈值时，该Follower副本将从ISR中移除。只有ISR中的副本才有资格被选为新的Leader，这确保了副本间的数据一致性。
 
+   ISR（in-sync replica）分区是Leader分区**同步复制**保存的一个队列，普通分区是Leader分区**异步复制**保存的一个队列。
 
-- **分区备份机制**
+   如果leader失效后，需要选出新的leader，选举的原则如下：
 
-  - 一个topic有多个分区，每个分区有多个副本，其中有一个leader，其余的是follower，副本存储在不同的broker中
-  - 所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader
+   - 第一：选举时优先从ISR中选定，因为这个列表中follower的数据是与leader同步的
+   - 第二：如果ISR列表中的follower都不行了，就只能从其他follower中选取
 
-  <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151700526.png" alt="image-20240415170035456" style="zoom:45%;" />
+   <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151707886.png" alt="image-20240415170718823" style="zoom:50%;" />
 
-- **分区副本复制机制**
+3. **多副本策略**：
 
-  - ISR（in-sync replica）分区是Leader分区**同步**复制保存的一个队列，普通分区是Leader分区**异步**复制保存的一个队列
-  - 如果leader失效后，需要选出新的leader，选举的原则如下：
-    - 第一：选举时优先从ISR中选定，因为这个列表中follower的数据是与leader同步的
-    - 第二：如果ISR列表中的follower都不行了，就只能从其他follower中选取
+   Kafka允许为每个分区配置多个副本，这些副本分布在不同的Broker上。这样即使某个Broker出现故障，也不会影响整个集群的服务能力。此外，合理的副本分配策略还可以提高数据的安全性和系统的容错性。
 
-  <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151707886.png" alt="image-20240415170718823" style="zoom:50%;" />
+   <img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202404151659488.png" alt="image-20240415165935408" style="zoom:45%;" />
 
 # 保证消息不丢失