doc: 1、备份文章；

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

@@ -1627,15 +1627,15 @@ public class WebMvcConfiguration extends WebMvcConfigurationSupport {
 
 AMQP（Advanced Message Queuing Protocol）是一种开放的标准协议，用于消息传递中间件。它提供了一种标准化的方法来实现消息传递系统之间的互操作性。AMQP 协议最初由金融行业提出，目的是为了实现跨组织的消息传递，但现在已被广泛应用于多种场景。
 
-# AMQP 的特点
+## 特点
 
 1. **开放标准**：AMQP 是一个公开的标准协议。
 2. **跨平台和语言**：AMQP 设计为跨平台和跨语言的协议，支持多种编程语言和操作系统。
 3. **安全性**：AMQP 支持安全的消息传递，包括认证、授权和加密。
 4. **可靠性**：AMQP 支持消息确认机制，确保消息的可靠传输。
 5. **灵活性**：AMQP 允许不同的消息传递模式，包括点对点（P2P）和发布/订阅（Pub/Sub）。
 
-# AMQP 的基本概念
+## 基本概念
 
 AMQP 协议定义了几个基本的概念，这些概念构成了消息传递的基础：
 
@@ -1645,15 +1645,17 @@ AMQP 协议定义了几个基本的概念，这些概念构成了消息传递的
 4. **队列（Queue）**：用于暂存消息，直到消费者准备好接收它们。
 5. **绑定（Binding）**：用于定义交换机和队列之间的关系，以及消息如何从交换机路由到队列。
 
-# AMQP 的消息格式
+# AMQP消息模型
+
+## 消息格式
 
 AMQP 消息通常包含以下几个部分：
 
 1. **头部（Header）**：包含消息的元数据，如优先级、TTL 等。
 2. **属性（Properties）**：包含消息的属性，如消息的唯一标识符、内容类型、内容编码等。
 3. **体（Body）**：包含消息的实际内容。
 
-# AMQP 的消息传递流程
+## 消息传递流程
 
 以下是 AMQP 消息传递的基本流程：
 
@@ -1664,7 +1666,7 @@ AMQP 消息通常包含以下几个部分：
 5. **接收消息**：消费者从队列中接收消息。
 6. **关闭通道和连接**：完成消息传递后，关闭通道和连接。
 
-# AMQP 的消息传递模型
+## 消息传递模型
 
 **点对点（P2P）模型**：
 
@@ -1678,10 +1680,16 @@ AMQP 消息通常包含以下几个部分：
 
 # 推模式 vs 拉模式
 
-## 推消息（Push）模式
+## 推消息（Push）模式的优势与局限
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202411191614001.png" alt="image-20241119161447428" style="zoom:50%;" />
 
 消息队列主动将消息发送给消费者。
 
+在**推送模型**中，数据流是由生产者主动向代理发送数据，随后代理根据预先设定的规则或策略，将数据推送给注册的消费者。这种模型的优点包括**较低的延迟**和**实时性更强**的数据传递。然而，推送模型也有明显的局限性。首先，它对网络带宽的要求较高，特别是在高并发场景下，大量的小数据包频繁传输会导致网络拥塞。其次，由于数据传输速率由代理控制，不同消费者之间的处理能力差异可能导致部分消费者无法及时处理接收到的数据，从而造成资源浪费或系统过载。特别是当**消费者的处理速度低于生产者的生成速度时，消费者可能会遭受类似拒绝服务攻击的情况，即被过多的数据淹没而无法正常工作。**
+
+在消息队列的推送模式中，**代理（Broker）需要记录和维护每个消费者的消费进度，以便准确地将未消费的消息推送给相应的消费者。**这是因为推送模式下，代理负责控制消息的发送时间和数量，确保每个消费者都能接收到它们尚未处理的消息。这种方式对代理的管理和协调能力要求较高，尤其是在消费者数量众多且处理能力不一的情况下，容易导致系统复杂度增加和性能瓶颈。
+
 **优点**：
 
 - 实时性强：消息可以立即传递给消费者，减少延迟。
@@ -1693,10 +1701,17 @@ AMQP 消息通常包含以下几个部分：
 - 处理失败：如果消费者未能及时处理消息，可能导致消息积压或丢失。
 - 资源消耗：持续保持连接可能会占用较多的资源，尤其是在高并发环境下。
 
-## 拉消息（Pull）模式
+## 拉消息（Pull）模式的优势与局限
 
 消费者主动从消息队列中获取消息。
 
+相比之下，**拉取模型**则采取了一种更为保守和灵活的方式。在这种模型中，数据由生产者发送到代理，但消费者需要主动发起请求以获取数据。这样做的好处：**消费者可以根据自身的处理能力和当前的工作负载情况，自主决定何时以及多少数据进行拉取。**即使在消费速度下降的情况下，消费者也只会暂时落后，而不会像在推送模型中那样被压垮。此外，拉取模型还支持更有效的数据**批处理**。消费者可以一次性拉取大量数据，从而减少网络交互次数，提高传输效率，同时保持较低的延迟。
+
+<img src="https://cdn.jsdelivr.net/gh/01Petard/imageURL@main/img/202411191621267.png" alt="image-20241119162106093" style="zoom:50%;" />
+
+**拉取模式下，消费者自己决定何时以及多少消息进行消费。消费者会主动向代理请求消息，代理只需提供消息存储和查询的功能即可。**这种方式减少了代理的负担，使其不必追踪每个消费者的消费进度，同时也赋予了消费者更大的灵活性，可以根据自身处理能力和当前负载情况自主调整消费速率。这种方式简化了系统设计，提高了系统的可扩展性和鲁棒性。
+然而，拉取模型并非没有挑战。最明显的问题是，如果代理中没有新的数据可供拉取，消费者可能会**频繁地发起空查询**，导致CPU利用率升高，形成所谓的“忙等（Bush-Waiting）”状态。为了解决这一问题，Kafka引l入了“长轮询”机制，允许消费者在发出拉取请求后，如果没有新的数据可拉取，该请求会在代理端等待一段时间，直到有新数据产生或达到预设的超时时间。这样既避免了频繁的空查询，又保证了数据的及时传递。
+
 **优点**：
 
 - 控制灵活性：消费者可以根据自己的处理能力和需求来决定何时拉取消息。
@@ -1708,13 +1723,16 @@ AMQP 消息通常包含以下几个部分：
 - 增加网络负载：频繁的轮询会导致额外的网络流量。
 - 延迟增加：由于需要消费者主动请求，所以消息传递可能不如推模式实时。
 
-> **Kafka是拉模式**，这使得 Kafka 很适合处理大量数据流的应用场景。
+# Kafka的选择与实践
+
+基于上述分析，Kafka选择了**拉取模型**作为其核心数据传输机制。这一选择不仅符合大多数消息系统的传统设计，还特别适合于需要处理大量异构消费者的应用场景。通过实现长轮询功能，**Kafka有效地平衡了数据传输的即时性和系统的稳定性，使得即使在网络条件不稳定或消费者处理能力有限的情况下，也能保持高效的数据交换。**此外，Kafka还通过优化数据批处理和调整拉取请求的参数，进一步提高了系统的整体性能。
+**Kafka的拉取模型更适合数据处理场景**，因为它允许消费者根据自身处理能力自主控制数据拉取的频率和数量，有效避免了消费者过载和资源浪费。**而在业务场景中，实时性和低延迟要求更高，推送模型能更好地满足这些需求。**
 
 ## 推拉结合（Push-Pull）模式
 
 推拉结合使用，可以结合两者的优点，提高消息传递的效率和可靠性。
 
-例如，消息队列可以先推送消息给消费者，然后消费者再拉取这些消息以确认处理状态。
+例如，消息队列可以先推送给消费者，然后消费者再拉取这些消息以确认处理状态。
 
 # RabbitMQ名词解释