📕我是廖志伟，一名Java开发工程师、《Java项目实战——深入理解大型互联网企业通用技术》（基础篇）、（进阶篇）、（架构篇）、《解密程序员的思维密码——沟通、演讲、思考的实践》作者、清华大学出版社签约作家、Java领域优质创作者、优快云博客专家、阿里云专家博主、51CTO专家博主、产品软文专业写手、技术文章评审老师、技术类问卷调查设计师、幕后大佬社区创始人、开源项目贡献者。
📘拥有多年一线研发和团队管理经验，研究过主流框架的底层源码(Spring、SpringBoot、SpringMVC、SpringCloud、Mybatis、Dubbo、Zookeeper)，消息中间件底层架构原理(RabbitMQ、RocketMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。
📙不定期分享高并发、高可用、高性能、微服务、分布式、海量数据、性能调优、云原生、项目管理、产品思维、技术选型、架构设计、求职面试、副业思维、个人成长等内容。
💡在这个美好的时刻，笔者不再啰嗦废话，现在毫不拖延地进入文章所要讨论的主题。接下来，我将为大家呈现正文内容。
🍊 RabbitMQ知识点之Time-To-Live：概述
在分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，我们常常会遇到这样一个问题：消息在队列中滞留时间过长，可能会占用过多的存储资源，甚至导致消息队列崩溃。为了解决这一问题，RabbitMQ 引入了 Time-To-Live（TTL）机制。
RabbitMQ 的 Time-To-Live 机制允许我们为消息设置一个存活时间，一旦消息在队列中超过这个时间，它就会被自动删除。这种机制对于确保消息队列的高效运行至关重要，尤其是在处理大量临时消息的场景中。
介绍 RabbitMQ 知识点之 Time-To-Live 的概述，是因为它不仅能够帮助我们优化消息队列的性能，还能够提高系统的稳定性。在分布式系统中，消息的及时处理和清理是保证系统健康运行的关键。通过 Time-To-Live 机制，我们可以有效地控制消息在队列中的生命周期，避免因消息堆积导致的资源浪费和系统崩溃。
接下来，我们将深入探讨 Time-To-Live 的概念介绍和作用与意义。首先，我们会详细解释 Time-To-Live 的具体含义，包括如何设置消息的存活时间以及如何处理超时的消息。随后，我们会分析 Time-To-Live 在实际应用中的作用，比如如何避免消息堆积、如何优化消息队列的性能，以及如何确保系统的稳定性。通过这些内容，读者将能够全面理解 Time-To-Live 机制，并在实际项目中有效地应用它。
🎉 RabbitMQ 中的 Time-To-Live (TTL) 概念介绍
在 RabbitMQ 中，Time-To-Live（简称 TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。下面，我将用通俗易懂的语言来介绍 TTL 的概念。
📝 什么是 TTL？
想象一下，你有一个快递，你希望这个快递在某个时间点之前送达，否则就不再有效。在 RabbitMQ 中，TTL 就是这样的一种机制，它允许你为消息设置一个存活时间。一旦消息在队列中超过了这个时间，它就会被自动删除。
📝 TTL 原理
RabbitMQ 的 TTL 原理相对简单。当你发送一个消息到一个队列时，你可以指定这个消息的 TTL。如果这个队列设置了 TTL，那么消息将在队列中存活指定的时间。如果在这个时间之前消息没有被消费，它就会被自动删除。
📝 消息过期机制
消息过期机制如下：
- 当消息被发送到队列时，如果设置了 TTL，消息会被标记为具有过期时间。
- 消息在队列中等待被消费。
- 如果在 TTL 设置的时间内消息没有被消费，它会被自动删除。
📝 过期时间设置
过期时间的设置可以在发送消息时指定，也可以在队列级别设置。以下是一个在发送消息时设置 TTL 的示例：
channel.basic_publish(exchange='exchange_name',
routing_key='routing_key',
body='message body',
properties=pika.BasicProperties(
delivery_mode=2, # 消息持久化
expiration='10000' # TTL 设置为 10000 毫秒
))
📝 队列过期策略
RabbitMQ 支持两种队列过期策略：
- 自动删除：当队列中的所有消息都被消费后，队列自动被删除。
- 手动删除：需要手动删除队列。
📝 死信队列
当消息过期时，它会被放入一个特殊的队列，这个队列被称为死信队列（Dead Letter Queue，简称 DLX）。你可以设置一个死信队列来处理这些过期的消息。
📝 消息持久化
消息持久化是 RabbitMQ 中的一个重要特性，它确保了即使 RabbitMQ 服务重启，消息也不会丢失。在设置 TTL 时，如果消息持久化，那么即使消息过期，它也会被保存在磁盘上。
📝 应用场景
TTL 在以下场景中非常有用：
- 临时消息：你需要处理一些临时消息，这些消息不需要永久存储。
- 限流：你可以使用 TTL 来限制消息在队列中的存活时间，从而实现限流功能。
📝 性能影响
TTL 会对 RabbitMQ 的性能产生一定的影响，因为它需要额外的计算来处理过期的消息。但是，这种影响通常是可以接受的。
📝 配置参数
以下是一些与 TTL 相关的配置参数：
x-message-ttl：设置消息的 TTL。x-dead-letter-exchange：设置死信队列的交换机。x-dead-letter-routing-key：设置死信队列的路由键。
📝 最佳实践
以下是一些关于 TTL 的最佳实践：
- 在发送消息时设置 TTL，而不是在队列级别设置。
- 使用死信队列来处理过期的消息。
- 不要设置过长的 TTL，以免浪费资源。
通过以上介绍，相信大家对 RabbitMQ 中的 TTL 有了一个清晰的认识。希望这些信息能帮助你在实际项目中更好地使用 RabbitMQ。
🎉 RabbitMQ中的Time-To-Live（TTL）机制：作用与意义
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。下面，我们将从多个维度来探讨TTL的作用与意义。
📝 1. TTL的作用
1.1 防止消息堆积
在分布式系统中，消息可能会因为各种原因（如消费者处理速度慢、系统故障等）导致在队列中堆积。TTL可以帮助我们设置一个时间限制，超过这个时间限制的消息将被自动删除，从而避免消息堆积。
1.2 确保消息时效性
有些消息可能只在特定时间段内有效，例如，订单支付通知、活动报名信息等。通过设置TTL，可以确保这些消息在过期后不再被处理，从而保证消息的时效性。
1.3 优化系统资源
当消息在队列中长时间未处理时，可能会占用队列资源，影响系统性能。TTL可以帮助我们清理这些无用的消息，从而优化系统资源。
📝 2. TTL的意义
2.1 提高系统稳定性
通过设置TTL，可以避免消息堆积，从而提高系统的稳定性。当系统出现故障时，未处理的消息会在TTL到期后被自动删除，减少系统压力。
2.2 保障数据一致性
在分布式系统中，数据一致性是一个重要的问题。通过设置TTL，可以确保消息在过期后不再被处理，从而保障数据一致性。
2.3 提高开发效率
TTL可以帮助开发人员更好地管理消息，提高开发效率。例如，在开发过程中，可以设置TTL来模拟消息过期，从而测试系统的容错能力。
📝 3. TTL的设置与使用
3.1 过期时间设置
在RabbitMQ中，可以通过以下方式设置消息的过期时间：
- 在消息发送时，使用
x-message-ttl属性设置过期时间（单位为毫秒）。 - 在队列声明时，使用
x-expires属性设置队列的过期时间。
3.2 消息重试策略
当消息在队列中过期时，可以将其发送到死信队列（Dead Letter Queue，DLQ）。在DLQ中，可以设置消息重试策略，例如，将消息重新发送到队列或将其删除。
3.3 消息持久化
为了确保消息在过期后仍然被保存，可以将消息设置为持久化。这样，即使消息在队列中过期，也可以在DLQ中找到。
📝 4. TTL与消息队列性能优化
4.1 消息延迟队列
通过设置TTL，可以将消息延迟一段时间再发送到队列。这种方式可以用于实现消息延迟队列，例如，订单支付通知可以在支付成功后延迟一段时间再发送。
4.2 消息路由策略
在RabbitMQ中，可以通过设置不同的TTL来实现消息路由策略。例如，可以将不同类型的消息发送到不同的队列，并设置不同的TTL，从而实现消息的差异化处理。
📝 5. TTL与系统稳定性保障
5.1 分布式系统设计
在分布式系统中，TTL可以帮助我们优化系统设计。例如，可以将TTL应用于消息队列、缓存、数据库等组件，从而提高系统的稳定性。
5.2 系统故障恢复
当系统出现故障时，TTL可以帮助我们快速恢复。例如，可以将过期消息重新发送到队列，从而确保系统正常运行。
通过以上分析，我们可以看出，TTL在RabbitMQ中具有重要的作用与意义。合理地设置和使用TTL，可以帮助我们提高系统的稳定性、保障数据一致性，并提高开发效率。
🍊 RabbitMQ知识点之Time-To-Live：配置与使用
在许多分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，我们常常会遇到这样的问题：消息在队列中滞留时间过长，导致队列长度无限增长，从而影响系统的性能和稳定性。为了解决这一问题，RabbitMQ 提供了 Time-To-Live（TTL）功能，允许我们为队列、消息或死信队列设置生存时间，一旦超时，相关消息将被自动移除。下面，我们将详细介绍 RabbitMQ 的 TTL 配置与使用方法。
RabbitMQ 的 TTL 知识点之所以重要，是因为它直接关系到消息队列的效率和系统的健康运行。在消息量庞大的系统中，如果不合理地管理消息的存活时间，可能会导致资源浪费和性能瓶颈。通过配置 TTL，我们可以确保消息在队列中不会无限期地滞留，从而优化资源利用，提高系统的响应速度。
接下来，我们将分别介绍以下三个方面：
-
队列TTL配置：我们将探讨如何为 RabbitMQ 队列设置 TTL，确保队列中的消息在指定时间内未被消费，则自动被移除。
-
消息TTL配置：我们将学习如何为单个消息设置 TTL，即使队列没有设置 TTL，消息也会在到达队列后的一定时间内被自动删除。
-
死信队列TTL配置：我们将介绍如何为死信队列设置 TTL，使得死信队列中的消息在指定时间内未被处理，则自动被清除。
通过这些内容的学习，读者将能够全面理解 RabbitMQ TTL 的配置和使用，从而在实际项目中更好地管理和优化消息队列。
🎉 队列TTL配置与消息过期机制
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它允许我们为消息设置一个过期时间。当消息在队列中停留超过这个时间时，它就会被自动删除。这种机制对于处理临时消息、清理过期数据以及优化消息队列的性能都非常有用。
📝 消息过期机制
消息过期机制是RabbitMQ中实现队列TTL的基础。以下是消息过期机制的关键点：
- 队列TTL：队列TTL是设置在队列层面的，它定义了队列中所有消息的最大存活时间。
- 消息TTL：消息TTL是设置在消息层面的，它定义了单个消息的最大存活时间。如果消息的TTL小于队列的TTL，那么消息会在到达队列时立即过期；如果消息的TTL大于队列的TTL，那么消息会在队列中存活至其TTL过期。
📝 过期消息处理策略
当消息过期时，RabbitMQ会将其从队列中移除。以下是几种常见的过期消息处理策略：
| 策略 | 描述 |
|---|---|
| 丢弃 | 默认策略，直接丢弃过期消息。 |
| 死信队列 | 将过期消息发送到一个特殊的队列，即死信队列。 |
| 重试 | 将过期消息重新放入队列，等待后续处理。 |
📝 队列生命周期管理
队列的生命周期管理包括创建、删除、修改队列属性等操作。以下是一些与TTL相关的队列生命周期管理操作：
- 创建队列时设置TTL：在创建队列时，可以指定队列的TTL。
- 修改队列TTL：可以在队列创建后修改其TTL。
- 删除队列：删除队列时，队列中的所有消息也会被删除。
📝 消息延迟投递
消息延迟投递是RabbitMQ提供的一种机制，它允许我们在指定的时间后发送消息。以下是如何使用延迟投递与TTL结合的示例：
```mermaid
graph TD
A[创建消息] --> B{设置消息TTL}
B -- 是 --> C[发送消息]
B -- 否 --> D[设置队列TTL]
C --> E[消息进入队列]
D --> F[消息进入队列]
E --> G[消息在队列中等待]
G --> H{消息是否过期}
H -- 是 --> I[消息过期]
H -- 否 --> J[消息被处理]
I --> K[消息被丢弃/重试/发送到死信队列]
J --> L[消息处理完成]
K --> M[消息处理完成]
#### 📝 消息过期时间设置
消息过期时间的设置取决于具体的业务需求。以下是一些设置消息过期时间的场景：
- **临时消息**：例如，订单支付通知，可以在消息中设置TTL为5分钟。
- **缓存数据**：例如，缓存中的用户信息，可以在消息中设置TTL为1小时。
#### 📝 过期消息重试机制
在某些情况下，我们可能需要重试处理过期消息。以下是如何实现过期消息重试机制的示例：
```java
// 假设有一个消息处理类 MessageHandler
public class MessageHandler {
public void handleMessage(String message) {
// 处理消息
}
}
// 假设有一个重试机制类 RetryHandler
public class RetryHandler {
public void retry(MessageHandler handler, String message) {
// 重试处理消息
handler.handleMessage(message);
}
}
📝 消息持久化与过期
消息持久化是指将消息存储在磁盘上，以确保消息不会因为系统故障而丢失。以下是如何将消息持久化与过期结合的示例：
// 假设有一个消息生产者类 MessageProducer
public class MessageProducer {
public void produce(String message, boolean persistent, int ttl) {
// 生产消息，设置持久化和TTL
}
}
📝 TTL配置与消息优先级
在RabbitMQ中，消息优先级是指消息的优先级高于其他消息。以下是如何将TTL与消息优先级结合的示例：
// 假设有一个消息生产者类 MessageProducer
public class MessageProducer {
public void produce(String message, boolean persistent, int ttl, int priority) {
// 生产消息，设置持久化、TTL和优先级
}
}
📝 TTL与死信队列
死信队列是一种特殊的队列，用于存储无法处理的消息。以下是如何将TTL与死信队列结合的示例：
// 假设有一个消息生产者类 MessageProducer
public class MessageProducer {
public void produce(String message, boolean persistent, int ttl, String deadLetterExchange) {
// 生产消息，设置持久化、TTL和死信交换机
}
}
📝 TTL与消息队列性能
TTL可以用来优化消息队列的性能，例如，清理过期消息可以减少队列的大小，从而提高消息处理速度。以下是一些关于TTL与消息队列性能的要点：
- 减少队列大小：清理过期消息可以减少队列的大小，从而提高消息处理速度。
- 避免消息堆积：通过设置合理的TTL，可以避免消息在队列中堆积过久。
- 提高系统稳定性：清理过期消息可以提高系统的稳定性，减少内存和磁盘的占用。
📝 TTL配置最佳实践
以下是一些关于TTL配置的最佳实践：
- 根据业务需求设置TTL：TTL的设置应该根据具体的业务需求来确定。
- 避免设置过长的TTL：过长的TTL会导致消息在队列中停留过久，从而降低消息处理速度。
- 使用死信队列：将过期消息发送到死信队列，以便后续处理。
- 监控TTL配置：定期监控TTL配置的效果，并根据实际情况进行调整。
🎉 RabbitMQ中的Time-To-Live（TTL）配置详解
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。下面，我们将从多个维度来详细探讨RabbitMQ中的TTL配置。
📝 TTL与消息过期
TTL是消息的存活时间，一旦消息在队列中超过了这个时间，它就会被自动删除。这个时间可以是固定的，也可以是动态的。
| 特性 | 描述 |
|---|---|
| 固定TTL | 消息在队列中存活固定的时间，无论是否被消费。 |
| 动态TTL | 消息在队列中存活的时间根据当前队列的长度动态调整。 |
📝 队列配置
在RabbitMQ中，TTL可以通过队列配置来实现。以下是一个简单的队列配置示例：
Map<String, Object> args = new HashMap<>();
args.put("x-message-ttl", 60000); // 设置TTL为60秒
Channel.queueDeclare("queue_name", false, false, false, args);
📝 TTL单位
TTL的单位可以是毫秒（ms）、秒（s）、分钟（min）、小时（h）等。以下是一个使用不同单位的示例：
Map<String, Object> args = new HashMap<>();
args.put("x-message-ttl", 60); // 设置TTL为60秒
args.put("x-expires", 3600); // 设置TTL为1小时
Channel.queueDeclare("queue_name", false, false, false, args);
📝 消息过期处理
当消息过期时，RabbitMQ会将其放入死信队列（Dead Letter Queue，DLQ）。以下是一个简单的死信队列配置示例：
Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "dead_letter_exchange");
args.put("x-dead-letter-routing-key", "dead_letter_key");
Channel.queueDeclare("queue_name", false, false, false, args);
📝 消息持久化
为了确保消息不会因为服务器故障而丢失，我们可以将消息设置为持久化。以下是一个消息持久化的示例：
BasicProperties props = new BasicProperties.Builder()
.deliveryMode(2) // 设置消息为持久化
.build();
Channel.basicPublish("", "queue_name", props, "message".getBytes());
📝 生产者配置
在RabbitMQ中，生产者不需要配置TTL，因为TTL是在队列层面进行设置的。但是，生产者需要确保消息是持久化的，以防止消息丢失。
BasicProperties props = new BasicProperties.Builder()
.deliveryMode(2) // 设置消息为持久化
.build();
Channel.basicPublish("", "queue_name", props, "message".getBytes());
📝 消费者配置
消费者不需要配置TTL，因为TTL是在队列层面进行设置的。但是，消费者需要确保消息被正确消费，以避免消息过期。
BasicConsumeConsumer consumer = new BasicConsumeConsumer();
Channel.basicConsume("queue_name", false, consumer);
📝 消息延迟
RabbitMQ不支持直接设置消息的延迟时间。但是，我们可以通过以下方式实现消息的延迟：
- 使用延迟队列。
- 使用外部定时任务。
📝 系统性能
TTL配置不当可能会导致系统性能问题。以下是一些可能导致性能问题的场景：
- 队列中存在大量过期的消息。
- 死信队列过大。
📝 应用场景
TTL在以下场景中非常有用：
- 需要处理临时消息的场景，例如订单超时。
- 需要处理敏感信息，例如用户密码。
- 需要处理高并发场景，例如秒杀活动。
通过以上内容，我们可以了解到RabbitMQ中的TTL配置及其相关概念。在实际应用中，我们需要根据具体场景来合理配置TTL，以确保系统性能和消息的可靠性。
🎉 RabbitMQ中的Time-To-Live（TTL）与死信队列（DLX）配置
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。一旦消息超过了这个时间限制，它就会被自动删除。这种机制对于处理临时消息和避免队列中消息堆积非常有用。而与之紧密相关的是死信队列（Dead Letter Exchange，DLX），它用于接收那些无法正常处理的消息。
📝 TTL配置
TTL的配置可以在多个层面上进行，以下是几个关键点：
- 队列级别：在创建队列时，可以指定TTL值。这个值是以毫秒为单位的，表示消息在队列中存活的最长时间。
- 消息级别：在发送消息时，可以给消息设置TTL。如果队列级别的TTL和消息级别的TTL同时存在，那么消息的存活时间取决于两者中较小的一个。
以下是一个队列级别TTL配置的示例：
```mermaid
graph TD
A[创建队列] --> B{设置TTL为10000毫秒}
B --> C[队列创建成功]
📝 消息过期机制
当消息在队列中存活时间达到TTL时，RabbitMQ会自动将消息标记为过期。以下是消息过期后的处理流程：
- 队列过期策略：如果队列设置了过期策略，那么过期的消息会被移除。
- 死信队列应用场景：如果没有设置过期策略，那么过期的消息会被发送到死信队列中。
以下是一个消息过期后的处理流程的示例：
```mermaid
graph TD
A[消息发送到队列] --> B{消息存活时间达到TTL}
B --> C[消息标记为过期]
C --> D{队列过期策略}
D --> |移除消息| E[队列]
D --> |发送到死信队列| F[死信队列]
📝 队列过期策略
队列过期策略有以下几种：
- **Discard：**直接丢弃消息。
- **Dead Letter Exchange：**将消息发送到死信队列。
- **Pass：**不做任何处理。
以下是一个队列过期策略的表格：
| 策略 | 描述 |
|---|---|
| Discard | 直接丢弃消息，不进行任何记录。 |
| Dead Letter Exchange | 将消息发送到死信队列，可以在死信队列中进行进一步处理。 |
| Pass | 不做任何处理，消息仍然在队列中。 |
📝 消息过期处理
当消息过期后，RabbitMQ会根据队列的过期策略进行处理。以下是几种常见的处理方式：
- 消息重试机制：如果消息无法处理，可以将其放入重试队列，等待一段时间后再次尝试处理。
- 消息持久化：将消息持久化到磁盘，确保消息不会因为系统故障而丢失。
- 消息延迟投递：将消息延迟一段时间后再次投递到队列中。
以下是一个消息过期处理的示例：
```mermaid
graph TD
A[消息发送到队列] --> B{消息存活时间达到TTL}
B --> C[消息标记为过期]
C --> D{消息重试机制}
D --> |重试消息| E[队列]
C --> F{消息持久化}
C --> G{消息延迟投递}
G --> |延迟后再次投递| H[队列]
📝 消息优先级
在RabbitMQ中，可以给消息设置优先级，优先级高的消息会被优先处理。这可以通过设置消息的priority属性来实现。
以下是一个消息优先级的示例：
```mermaid
graph TD
A[消息发送到队列] --> B{设置消息优先级为5}
B --> C[优先级高的消息被优先处理]
📝 消息路由策略
RabbitMQ支持多种消息路由策略，如直接路由、主题路由、扇形路由等。这些策略可以根据消息的内容和队列的需求进行选择。
以下是一个消息路由策略的示例：
```mermaid
graph TD
A[消息发送到交换机] --> B{根据消息内容选择路由键}
B --> C[消息路由到队列]
📝 生产者消费者模式
RabbitMQ支持生产者消费者模式，生产者负责发送消息，消费者负责接收消息。这种模式可以有效地解耦生产者和消费者，提高系统的可扩展性。
以下是一个生产者消费者模式的示例：
```mermaid
graph TD
A[生产者发送消息] --> B[消息发送到交换机]
B --> C[消息路由到队列]
C --> D[消费者接收消息]
📝 消息确认机制
在RabbitMQ中，消费者可以通过确认机制来告知RabbitMQ消息已经被成功处理。这样可以确保消息不会因为消费者故障而丢失。
以下是一个消息确认机制的示例：
```mermaid
graph TD
A[消费者接收消息] --> B{消息处理成功}
B --> C[发送确认消息给RabbitMQ]
📝 消息监听器
RabbitMQ支持消息监听器，可以监听队列中的消息，并在消息到达时执行相应的操作。
以下是一个消息监听器的示例：
```mermaid
graph TD
A[消息到达队列] --> B{消息监听器执行操作}
📝 消息队列监控与运维
RabbitMQ提供了丰富的监控和运维工具，可以帮助管理员监控队列的性能和状态，及时发现并解决问题。
以下是一个消息队列监控与运维的示例：
```mermaid
graph TD
A[监控队列性能] --> B{分析数据}
B --> C{发现问题}
C --> D{解决问题}
通过以上内容，我们可以看到RabbitMQ中的TTL和死信队列配置在消息处理中扮演着重要的角色。合理地配置TTL和死信队列，可以提高系统的稳定性和性能。
🍊 RabbitMQ知识点之Time-To-Live：工作原理
在许多分布式系统中，消息队列扮演着至关重要的角色，它负责在系统组件之间传递消息，确保数据在不同服务之间可靠地流动。然而，在实际应用中，我们可能会遇到一些场景，比如当消息发送后，由于某些原因（如目标服务暂时不可用），消息需要被存储一段时间后再被处理。这就引出了RabbitMQ中的Time-To-Live（TTL）特性，它允许我们为消息设置一个存活时间，一旦消息超过了这个时间限制，它就会被自动删除。
RabbitMQ的TTL工作原理对于确保消息队列中的数据不会无限期地堆积至关重要。在消息队列中，如果消息没有被及时消费，可能会占用过多的存储空间，甚至可能导致系统性能下降。因此，了解RabbitMQ的TTL机制及其工作原理对于维护一个高效、稳定的消息队列系统至关重要。
接下来，我们将深入探讨RabbitMQ的TTL机制，首先会介绍消息过期机制，即如何为消息设置TTL，以及消息在达到TTL后会发生什么。随后，我们会讨论过期消息的处理方式，包括如何从队列中移除过期消息，以及如何处理这些被移除的消息，比如是否需要记录日志、是否需要发送通知等。
通过了解这些内容，读者将能够全面掌握RabbitMQ的TTL特性，从而在设计和维护消息队列时，能够根据实际需求合理地设置消息的存活时间，确保系统资源的有效利用和消息处理的及时性。
🎉 RabbitMQ中的Time-To-Live（TTL）与消息过期机制
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息达到队列后，如果没有在指定的时间内被消费，它就会被视为过期，并按照队列的过期策略进行处理。
📝 过期时间设置
RabbitMQ支持在消息发送时设置TTL，也可以在队列级别设置TTL。以下是一个简单的代码示例，展示如何在消息发送时设置TTL：
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.expiration("10000") // 设置TTL为10000毫秒
.build();
channel.basicPublish(exchange, routingKey, props, body);
在上述代码中，expiration参数指定了消息的TTL，单位为毫秒。
📝 过期策略
RabbitMQ提供了两种过期策略：
- 队列过期：当消息在队列中达到TTL时，它会被自动删除。
- 死信队列：当消息在队列中达到TTL时，它会被发送到一个指定的死信队列。
以下是一个表格，对比了这两种策略：
| 策略 | 描述 |
|---|---|
| 队列过期 | 消息在队列中达到TTL后，会被自动删除。 |
| 死信队列 | 消息在队列中达到TTL后，会被发送到一个指定的死信队列。 |
📝 消息持久化
为了确保消息不会因为服务器的重启而丢失，我们可以将消息设置为持久化。以下是一个代码示例，展示如何在消息发送时设置消息持久化：
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.expiration("10000") // 设置TTL为10000毫秒
.deliveryMode(2) // 设置消息持久化
.build();
channel.basicPublish(exchange, routingKey, props, body);
在上述代码中，deliveryMode参数设置为2，表示消息持久化。
📝 过期消息处理
当消息过期后，RabbitMQ会根据队列的过期策略进行处理。以下是几种常见的处理方式：
- 消息延迟：将过期消息发送到一个延迟队列，等待一段时间后再次尝试发送。
- 消息重试：将过期消息发送到一个重试队列，等待一段时间后再次尝试消费。
- 消息延迟队列：将过期消息发送到一个延迟队列，等待一段时间后再次尝试发送。
📝 过期消息监控
为了监控过期消息，我们可以使用RabbitMQ的管理界面或者编写自定义脚本。以下是一个简单的Mermaid代码示例，展示如何使用Mermaid绘制一个流程图：
graph TD
A[消息发送] --> B{消息是否过期?}
B -- 是 --> C[消息过期处理]
B -- 否 --> D[消息正常处理]
C --> E[消息延迟队列]
C --> F[消息重试队列]
D --> G[消息消费]
📝 过期消息通知
当消息过期时，我们可以通过发送通知来提醒相关人员。以下是一个简单的代码示例，展示如何发送过期消息通知：
String message = "消息过期，请处理！";
channel.basicPublish(exchange, "notification", null, message.getBytes());
📝 过期消息统计
为了统计过期消息的数量，我们可以使用RabbitMQ的管理界面或者编写自定义脚本。以下是一个简单的代码示例，展示如何统计过期消息的数量：
int expiredMessagesCount = channel.queueDeclare("expired_queue", true, false, false, null).getMessageCount();
System.out.println("过期消息数量：" + expiredMessagesCount);
📝 过期消息恢复
当消息过期后，我们可以将它们恢复到队列中，以便再次尝试消费。以下是一个简单的代码示例，展示如何恢复过期消息：
String message = "消息过期，请处理！";
channel.basicPublish(exchange, routingKey, null, message.getBytes());
📝 过期消息删除策略
当消息过期后，我们可以根据实际情况选择删除策略。以下是一些常见的删除策略：
- 自动删除：当消息过期后，自动从队列中删除。
- 手动删除：当消息过期后，手动从队列中删除。
📝 过期消息备份
为了防止数据丢失，我们可以将过期消息备份到其他存储系统中。以下是一个简单的代码示例，展示如何备份过期消息：
String message = "消息过期，请处理！";
channel.basicPublish(exchange, "backup_exchange", null, message.getBytes());
📝 过期消息归档
为了方便查询和统计，我们可以将过期消息归档到其他存储系统中。以下是一个简单的代码示例，展示如何归档过期消息：
String message = "消息过期，请处理！";
channel.basicPublish(exchange, "archive_exchange", null, message.getBytes());
通过以上内容，我们可以了解到RabbitMQ中的Time-To-Live（TTL）与消息过期机制的相关知识。在实际应用中，我们需要根据业务需求选择合适的过期策略和处理方式，以确保消息的可靠性和系统的稳定性。
🎉 RabbitMQ中的Time-To-Live（TTL）与过期消息处理
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它允许我们设置消息的存活时间。一旦消息在队列中超过了这个时间，它就会被自动删除。这种机制对于处理过期消息非常有用，下面我们将详细探讨这一机制。
📝 消息过期机制
RabbitMQ提供了两种设置消息TTL的方式：
- 队列级别的TTL：在创建队列时，可以设置队列的TTL，所有进入该队列的消息都会被赋予相同的存活时间。
- 消息级别的TTL：在发送消息时，可以给每条消息单独设置TTL。
以下是一个表格，对比了这两种设置方式：
| 设置方式 | 优点 | 缺点 |
|---|---|---|
| 队列级别的TTL | 简单易用，所有消息都有相同的存活时间 | 无法为不同消息设置不同的存活时间 |
| 消息级别的TTL | 可以根据消息的重要性设置不同的存活时间 | 需要为每条消息单独设置TTL |
📝 过期消息队列
当消息过期后，它会被放入一个特殊的队列，这个队列被称为过期消息队列。这个队列中的消息会被RabbitMQ自动处理，通常情况下，它们会被删除。
📝 消息过期时间设置
设置消息的TTL非常简单，以下是一个使用RabbitMQ Java客户端的示例：
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.expiration("10000") // 设置TTL为10000毫秒
.build();
channel.basicPublish(exchange, routingKey, props, body);
在上面的代码中，我们设置了消息的TTL为10000毫秒。
📝 消息过期策略
当消息过期后，RabbitMQ会根据队列的配置来处理这些消息。以下是一些常见的策略：
- 删除消息：这是默认策略，RabbitMQ会自动删除过期消息。
- 将消息发送到死信队列：如果队列配置了死信交换器，过期消息会被发送到这个交换器，然后根据交换器的配置路由到相应的队列。
📝 消息持久化
为了确保消息不会因为服务器故障而丢失，我们可以将消息设置为持久化。这样，即使服务器重启，消息也不会丢失。
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.expiration("10000") // 设置TTL为10000毫秒
.deliveryMode(2) // 设置消息为持久化
.build();
channel.basicPublish(exchange, routingKey, props, body);
在上面的代码中，我们设置了消息的持久化。
📝 消息重试机制
在某些情况下，我们可能需要重试发送消息。RabbitMQ提供了重试机制，允许我们在消息过期后重试发送。
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.expiration("10000") // 设置TTL为10000毫秒
.deliveryMode(2) // 设置消息为持久化
.build();
channel.basicPublish(exchange, routingKey, props, body);
在上面的代码中，我们设置了消息的重试机制。
📝 消息死信队列
当消息过期后，如果队列配置了死信交换器，过期消息会被发送到这个交换器。然后，根据交换器的配置，这些消息会被路由到相应的队列。
📝 消息过期通知
当消息过期时，我们可以通过监听队列来获取通知。
channel.basicConsume(queue, consumerTag, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
// 处理消息
}
});
在上面的代码中，我们监听了队列，当消息过期时，会触发handleDelivery方法。
📝 消息过期处理流程
以下是消息过期处理的基本流程：
- 消息进入队列。
- 消息在队列中等待被消费。
- 如果消息在队列中超过了TTL，它会被自动删除。
- 如果队列配置了死信交换器，过期消息会被发送到这个交换器。
- 根据交换器的配置，这些消息会被路由到相应的队列。
📝 消息过期性能影响
消息过期机制可能会对性能产生一定的影响，特别是在高并发场景下。因此，在设计和实现消息过期机制时，需要考虑性能因素。
📝 消息过期监控与报警
为了确保消息过期机制正常运行，我们需要对其进行监控和报警。以下是一些监控和报警的方法：
- 监控队列中的消息数量。
- 监控过期消息的数量。
- 设置报警阈值，当超过阈值时，发送报警信息。
📝 消息过期处理最佳实践
以下是一些处理消息过期的最佳实践：
- 根据业务需求设置合理的TTL。
- 使用消息持久化来确保消息不会丢失。
- 使用消息重试机制来处理失败的消息。
- 使用消息死信队列来处理无法处理的消息。
- 监控和报警来确保消息过期机制正常运行。
通过以上内容，我们可以了解到RabbitMQ中的Time-To-Live（TTL）与过期消息处理的相关知识。在实际应用中，我们需要根据业务需求来设计和实现消息过期机制，以确保系统的稳定性和可靠性。
🍊 RabbitMQ知识点之Time-To-Live：性能优化
在分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，消息队列的性能优化是一个不容忽视的问题。以RabbitMQ为例，Time-To-Live（TTL）是RabbitMQ提供的一种性能优化手段，它可以帮助我们管理消息的生命周期，防止消息在队列中无限期地堆积。
场景问题：假设我们有一个系统，它需要处理大量的订单消息。由于业务规则，每个订单消息的有效期是有限的，一旦订单处理完成，该消息就应该被移除。如果没有TTL机制，这些过期的订单消息可能会在队列中无限期地占用资源，导致队列长度不断增长，最终影响系统的性能和稳定性。
为什么需要介绍这个知识点：Time-To-Live在RabbitMQ中非常重要，因为它能够帮助我们自动清理过期的消息，从而优化队列的性能。通过设置TTL，我们可以确保消息不会无限制地堆积在队列中，这对于维护系统的健康运行至关重要。此外，TTL的合理使用还可以减少存储成本，提高系统的资源利用率。
接下来，我们将对Time-To-Live的两种具体应用进行概述：
-
队列长度限制：通过为队列设置TTL，我们可以限制队列中消息的最大存活时间。一旦消息达到这个时间限制，它就会被自动移除队列，从而避免队列长度无限增长的问题。
-
消息批量处理：在处理大量消息时，我们可以利用TTL来控制消息的批量处理。通过合理设置TTL，我们可以确保在处理完一批消息后，下一批消息能够及时到达，从而提高系统的处理效率。
通过以上两种应用，我们可以看到Time-To-Live在RabbitMQ性能优化中的重要作用。接下来，我们将深入探讨这两种应用的具体实现和优化策略。
🎉 RabbitMQ 中的 Time-To-Live（TTL）与队列长度限制
在 RabbitMQ 中，Time-To-Live（TTL）和队列长度限制是两个重要的概念，它们对于确保消息队列的高效运行和数据的正确处理起着至关重要的作用。
📝 Time-To-Live（TTL）
TTL 是指消息在队列中存活的时间。当消息进入队列后，如果超过了设定的 TTL 时间，那么该消息将会被自动删除。TTL 可以设置在消息级别或队列级别。
- 消息级别 TTL：在发送消息时，为每条消息指定一个 TTL 值。如果消息在队列中未在指定时间内被消费，则会被自动删除。
- 队列级别 TTL：为整个队列设置一个 TTL 值。如果消息在队列中未在指定时间内被消费，则会被自动删除。
📝 队列长度限制
队列长度限制是指队列中可以存储的最大消息数量。当队列达到长度限制时，新的消息将无法进入队列，直到队列中的某些消息被消费。
| 特性对比 | 消息级别 TTL | 队列级别 TTL |
|---|---|---|
| 适用场景 | 适用于需要为每条消息设置不同存活时间的场景。 | 适用于需要为整个队列设置统一存活时间的场景。 |
| 优先级 | 消息级别的 TTL 优先级高于队列级别的 TTL。 | 队列级别的 TTL 优先级高于消息级别的 TTL。 |
| 设置方式 | 在发送消息时指定。 | 在创建队列时指定。 |
📝 消息过期时间与队列存储策略
消息过期时间与队列存储策略密切相关。以下是一些常见的队列存储策略：
- 持久化：将消息存储在磁盘上，即使 RabbitMQ 重启后也不会丢失。
- 非持久化：将消息存储在内存中，重启后消息会丢失。
| 策略 | 优点 | 缺点 |
|---|---|---|
| 持久化 | 数据安全，即使 RabbitMQ 重启也不会丢失。 | 性能较低，因为需要将消息写入磁盘。 |
| 非持久化 | 性能较高，因为消息存储在内存中。 | 数据不安全，重启后消息会丢失。 |
📝 消息持久化与消息延迟队列
消息持久化是指将消息存储在磁盘上，即使 RabbitMQ 重启后也不会丢失。消息延迟队列是指消息在队列中等待一定时间后才会被消费。
// Java 代码示例：创建一个持久化队列，并设置消息延迟时间为 10 秒
Queue queue = channel.queueDeclare("delayed_queue", true, false, false, new HashMap<String, Object>() {{
put("x-dead-letter-exchange", "delayed_exchange");
put("x-dead-letter-routing-key", "delayed");
put("x-message-ttl", 10000); // 10 秒
}});
📝 队列容量监控与队列性能优化
队列容量监控是指实时监控队列中的消息数量，以便及时发现和处理队列拥堵问题。以下是一些队列性能优化方法：
- 增加队列容量：根据业务需求，适当增加队列容量。
- 提高消费速度：优化消费者代码，提高消费速度。
- 使用延迟队列：将消息延迟一段时间再消费，减轻队列压力。
📝 消息重试机制与死信队列
消息重试机制是指当消费者无法处理消息时，将消息重新放入队列，等待后续处理。死信队列是指存储无法处理的消息的队列。
// Java 代码示例：创建一个死信队列
Queue deadLetterQueue = channel.queueDeclare("dead_letter_queue", true, false, false, null);
channel.queueBind(deadLetterQueue, "exchange", "dead_letter_routing_key");
📝 消息分发策略
消息分发策略是指将消息分配给不同的消费者。以下是一些常见的消息分发策略：
- 轮询分发：将消息依次分配给消费者。
- 随机分发：将消息随机分配给消费者。
- 广播分发：将消息同时发送给所有消费者。
📝 集群部署与扩展
集群部署是指将多个 RabbitMQ 服务器组成一个集群，以提高系统的可用性和性能。以下是一些 RabbitMQ 集群部署方法：
- 镜像队列：将队列镜像到多个节点，提高数据安全性。
- 镜像交换机：将交换机镜像到多个节点，提高消息路由的可靠性。
📝 消息队列最佳实践
- 合理设置 TTL：根据业务需求，合理设置消息的 TTL 值。
- 优化队列存储策略：根据业务需求，选择合适的队列存储策略。
- 监控队列性能：实时监控队列性能，及时发现和处理问题。
- 合理设置队列长度限制：根据业务需求，合理设置队列长度限制。
- 使用消息重试机制和死信队列：提高消息处理成功率，降低系统压力。
🎉 RabbitMQ 中的 Time-To-Live（TTL）与消息批量处理策略
在 RabbitMQ 中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息的 TTL 到期时，RabbitMQ 会自动将消息从队列中移除。这种机制对于实现消息的过期处理、消息的批量处理以及消息的延迟队列等功能至关重要。
📝 TTL 与消息批量处理
在消息批量处理场景中，TTL 可以帮助我们实现以下功能：
- 自动清理过期消息：通过设置 TTL，我们可以确保队列中的消息不会无限期地积累，从而避免队列过载。
- 实现消息的批量处理：结合 TTL 和消息的优先级，我们可以实现消息的批量处理，确保高优先级的消息能够优先被处理。
以下是一个使用 TTL 实现消息批量处理的示例：
```mermaid
graph TD
A[消息生产者] --> B{消息是否设置TTL?}
B -- 是 --> C[消息设置TTL值]
B -- 否 --> D[消息不设置TTL]
C --> E[消息进入队列]
D --> F[消息进入队列]
E --> G[消息过期]
F --> H[消息过期]
G --> I[消息被自动移除]
H --> J[消息被自动移除]
#### 📝 表格：TTL 与消息批量处理策略对比
| 策略 | 特点 | 优点 | 缺点 |
| --- | --- | --- | --- |
| TTL | 通过设置消息的存活时间，实现消息的自动过期 | 自动清理过期消息，避免队列过载 | 需要手动设置 TTL，可能存在消息处理不及时的情况 |
| 消息优先级 | 根据消息的优先级进行排序，优先处理高优先级消息 | 高优先级消息能够得到及时处理 | 需要设置消息优先级，可能存在优先级设置错误的情况 |
#### 📝 消息批量处理策略
在实际应用中，我们可以结合 TTL 和消息优先级，实现以下几种消息批量处理策略：
1. **按时间顺序处理**：设置消息的 TTL，确保队列中的消息按照时间顺序进行处理。
2. **按优先级处理**：设置消息的优先级，确保高优先级消息能够优先被处理。
3. **混合处理**：结合 TTL 和消息优先级，实现消息的混合处理。
### 🎉 总结
RabbitMQ 中的 TTL 功能对于实现消息的过期处理、消息的批量处理以及消息的延迟队列等功能至关重要。通过合理设置 TTL 和消息优先级，我们可以实现高效的消息批量处理策略，提高系统的性能和稳定性。
## 🍊 RabbitMQ知识点之Time-To-Live：应用场景
在许多分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，我们经常会遇到一些场景，比如需要确保消息在特定时间内被处理，或者在某些情况下，我们希望消息在达到一定时间后自动失效。这就引出了RabbitMQ中的Time-To-Live（TTL）特性，它允许我们为消息设置一个存活时间，一旦消息超过了这个时间限制，它就会被自动处理或删除。
例如，在一个电商系统中，订单消息需要在一定时间内被处理，如果订单在30分钟后仍未被处理，那么系统可能会自动将其标记为异常，并触发相应的处理流程。这种情况下，RabbitMQ的TTL特性就非常有用，因为它可以帮助我们确保消息在规定的时间内得到处理，从而提高系统的响应速度和稳定性。
介绍RabbitMQ的TTL特性对于理解和应用消息队列至关重要。它不仅能够帮助我们避免消息堆积，减少资源浪费，还能够确保系统在面临高负载时能够正常运作。接下来，我们将深入探讨两个与TTL相关的知识点：消息过期处理和消息延迟处理。
在“RabbitMQ知识点之Time-To-Live：消息过期处理”中，我们将学习如何为消息设置过期时间，以及当消息过期后，RabbitMQ是如何处理这些消息的。这包括消息被自动删除、重新入队或发送到特定的队列等。
而在“RabbitMQ知识点之Time-To-Live：消息延迟处理”中，我们将了解如何使用TTL来实现消息的延迟投递。这通常涉及到将消息发送到一个带有延迟队列的交换器，然后根据消息的TTL设置，延迟一定时间后将其投递到目标队列。
通过这两个知识点的学习，读者将能够更好地掌握RabbitMQ的TTL特性，并在实际项目中有效地利用它来优化消息处理流程。
### 🎉 RabbitMQ中的Time-To-Live（TTL）与消息过期处理
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息的TTL过期后，RabbitMQ会自动将消息标记为过期，并按照过期策略进行处理。
#### 📝 TTL与消息过期
**TTL定义**：TTL是消息的存活时间，它可以是绝对时间（如5秒、10分钟等），也可以是相对时间（如“发布消息后5秒”）。当消息的TTL过期后，RabbitMQ会将其从队列中移除。
**消息过期策略**：
| 策略 | 描述 |
| --- | --- |
| **自动删除** | 当消息过期后，RabbitMQ会自动将其从队列中删除。 |
| **发送到死信队列** | 当消息过期后，RabbitMQ会将其发送到指定的死信队列中。 |
#### 📝 表格：TTL与消息过期策略对比
| 策略 | 描述 | 优点 | 缺点 |
| --- | --- | --- | --- |
| 自动删除 | 消息过期后自动删除 | 简单易用 | 无法追踪过期消息 |
| 发送到死信队列 | 消息过期后发送到死信队列 | 可以追踪过期消息，便于后续处理 | 死信队列管理复杂 |
#### 📝 消息持久化与队列配置
**消息持久化**：为了确保消息不会因为服务重启而丢失，可以将消息设置为持久化。持久化消息在内存中存储，并在磁盘上进行备份。
**队列配置**：在创建队列时，可以设置队列的TTL属性，从而为队列中的所有消息指定TTL。
```java
Map<String, Object> args = new HashMap<>();
args.put("x-message-ttl", 5000); // 设置队列TTL为5秒
Channel channel = connection.createChannel();
channel.queueDeclare("queue_name", true, false, false, args);
📝 过期消息处理
处理方式：
- 自动删除：当消息过期后，RabbitMQ会自动将其从队列中删除。
- 发送到死信队列：当消息过期后，RabbitMQ会将其发送到指定的死信队列中。
📝 死信队列
死信队列：死信队列是用于存储无法正常消费的消息的队列。当消息过期、队列长度超过限制或消息被拒绝时，RabbitMQ会将消息发送到死信队列。
📝 消息重试机制
消息重试机制：当消息处理失败时，可以设置消息的重试次数。当重试次数达到上限后，消息会被发送到死信队列。
BasicProperties props = new BasicProperties.Builder()
.deliveryMode(2) // 设置消息为持久化
.expiration("10000") // 设置消息TTL为10秒
.build();
channel.basicPublish("", "queue_name", props, message.getBytes());
📝 过期消息监控
监控方式：
- 日志记录：记录消息过期事件，便于后续分析。
- 监控工具：使用RabbitMQ自带的监控工具，如RabbitMQ Management插件，实时监控过期消息。
📝 过期消息恢复策略
恢复策略：
- 手动处理：人工检查死信队列中的过期消息，并对其进行处理。
- 自动处理：编写脚本或程序，自动处理死信队列中的过期消息。
📝 应用场景分析
应用场景：
- 订单处理：当订单处理超时时，可以将订单消息发送到死信队列，并进行后续处理。
- 任务调度：当任务执行超时时，可以将任务消息发送到死信队列，并进行后续处理。
📝 性能影响评估
性能影响：
- 内存消耗：消息持久化会增加内存消耗。
- 磁盘IO：消息持久化会增加磁盘IO。
总结：
RabbitMQ中的TTL与消息过期处理是保证消息可靠性和系统稳定性的重要手段。在实际应用中，应根据业务需求选择合适的过期策略和处理方式，以确保系统的高效运行。
🎉 RabbitMQ中的Time-To-Live（TTL）与消息延迟处理
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息的TTL过期后，消息会被自动删除。这一机制在处理消息延迟和过期消息方面非常有用。
📝 消息延迟处理场景
在许多应用场景中，我们需要对消息进行延迟处理，例如：
- 订单超时处理：当用户下单后，系统需要等待一段时间（例如30分钟）来确认订单是否有效。如果在这段时间内没有收到用户的确认，系统可以自动取消订单。
- 邮件发送：发送邮件时，可能需要等待一段时间（例如24小时）后再发送，以确保邮件在用户活跃时间发送。
- 任务调度：在任务调度系统中，某些任务可能需要在特定时间执行，而不是立即执行。
📝 消息延迟处理策略
为了实现消息延迟处理，我们可以采用以下策略：
- 使用TTL：在消息发送到队列时，设置一个TTL值。当TTL过期后，消息会被自动删除。
- 使用延迟队列：延迟队列是一种特殊的队列，它允许消息在指定的时间后才能被消费。
下面是使用TTL实现消息延迟处理的示例：
// 设置TTL为30分钟
MessageProperties props = MessageProperties.PERSISTENT_TEXT_MESSAGE;
props.setExpiration("30000");
// 发送消息
channel.basicPublish("", "order_queue", props, "Order message".getBytes());
📝 消息延迟处理性能优化
为了优化消息延迟处理性能，我们可以采取以下措施：
- 合理设置TTL：TTL值不宜过大或过小。过大可能导致资源浪费，过小可能导致消息处理不及时。
- 使用批量处理：在处理大量消息时，可以使用批量处理来提高效率。
- 优化队列配置：合理配置队列参数，如队列大小、消费者数量等，可以提高消息处理性能。
📝 对比与列举
| 特性 | TTL | 延迟队列 |
|---|---|---|
| 实现方式 | 在消息发送时设置TTL值 | 使用特殊的队列实现 |
| 优点 | 简单易用，易于理解 | 功能强大，支持多种延迟策略 |
| 缺点 | 需要手动设置TTL值 | 实现复杂，需要额外的资源 |
📝 消息持久化与死信队列
消息持久化是指将消息存储在磁盘上，以确保消息不会因为系统故障而丢失。在RabbitMQ中，可以通过设置消息的持久化标志来实现。
死信队列是一种特殊的队列，用于存储无法正常处理的消息。当消息被拒绝、过期或队列达到最大长度时，消息会被发送到死信队列。
📝 消息重试机制
消息重试机制用于处理因某些原因导致消息处理失败的情况。在RabbitMQ中，可以通过设置消息的重试次数来实现。
📝 总结
RabbitMQ中的TTL和消息延迟处理机制在处理消息过期和延迟消息方面非常有用。通过合理配置和使用这些机制，可以提高消息处理性能和可靠性。
🍊 RabbitMQ知识点之Time-To-Live：常见问题与解决方案
在许多分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，我们经常会遇到一些与消息队列相关的问题，其中RabbitMQ的Time-To-Live（TTL）特性就是一个容易引发困惑的环节。想象一下这样的场景：一个系统需要处理大量的订单消息，这些消息在处理完成后应该被删除，以避免数据冗余。如果这些消息在处理过程中因为某些原因未能及时被消费，它们就会过期。那么，如何确保这些过期的消息能够被妥善处理，而不是无限期地占用系统资源呢？这就引出了RabbitMQ的Time-To-Live特性及其常见问题与解决方案。
RabbitMQ的Time-To-Live特性允许我们为消息设置一个存活时间，一旦消息在这个时间范围内没有被消费，它就会被自动删除。这对于保证消息队列的清洁和系统的稳定性至关重要。然而，在实际操作中，我们可能会遇到以下问题：
-
消息过期后无法消费：当消息过期时，如果没有相应的消费者来处理它，那么这个消息就会被丢弃。这可能导致重要信息丢失，影响系统的正常运行。
-
死信队列消息过多：由于某些原因，如消费者处理失败或网络问题，消息可能会被发送到死信队列。如果死信队列中的消息过多，它可能会占用大量的系统资源，甚至导致系统崩溃。
介绍RabbitMQ的Time-To-Live特性及其常见问题与解决方案的重要性在于，它能够帮助我们更好地管理和维护消息队列，确保系统的稳定性和数据的完整性。接下来，我们将分别探讨这两个问题，并提供相应的解决方案。首先，我们将分析消息过期后无法消费的原因，并介绍如何通过设置合适的过期策略来避免这种情况的发生。随后，我们将讨论死信队列中消息过多的问题，并介绍如何有效地管理和清理死信队列，以减轻系统负担。通过这些内容，读者将能够全面了解RabbitMQ的Time-To-Live特性，并在实际应用中更好地利用这一特性。
🎉 RabbitMQ中的Time-To-Live（TTL）与消息过期
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息的TTL过期后，如果消费者还没有消费这条消息，那么这条消息就会被视为无法消费，并可能进入死信队列。下面，我们将从多个维度详细探讨这一过程。
📝 消息生命周期与过期策略
| 维度 | 描述 |
|---|---|
| 消息生命周期 | 消息从生产者发送到RabbitMQ，经过队列，最终被消费者消费的过程。 |
| 过期策略 | 消息在队列中存活的时间，超过这个时间后，消息将被视为过期。 |
在RabbitMQ中，消息的生命周期可以分为以下几个阶段：
- 生产者发送消息：生产者将消息发送到RabbitMQ。
- 消息进入队列：消息被存储在队列中，等待消费者消费。
- 消费者消费消息：消费者从队列中取出消息并消费。
- 消息过期：如果消息设置了TTL，且在TTL时间内没有被消费，则消息过期。
- 消息进入死信队列：过期的消息会被发送到死信队列。
📝 队列配置与消息持久化
| 维度 | 描述 |
|---|---|
| 队列配置 | 队列的配置包括队列名称、队列类型、队列持久化等。 |
| 消息持久化 | 将消息持久化到磁盘，确保消息不会因为系统故障而丢失。 |
在RabbitMQ中，队列配置和消息持久化是保证消息可靠性的关键。以下是一些常见的队列配置和消息持久化方法：
- 队列持久化：将队列持久化到磁盘，确保队列不会因为系统故障而丢失。
- 消息持久化：将消息持久化到磁盘，确保消息不会因为系统故障而丢失。
- TTL设置：为队列或消息设置TTL，确保消息在队列中存活的时间。
📝 消费者行为与死信队列
| 维度 | 描述 |
|---|---|
| 消费者行为 | 消费者从队列中取出消息并消费。 |
| 死信队列 | 无法消费的消息会被发送到死信队列。 |
消费者在消费消息时，可能会遇到以下情况：
- 消息正常消费：消费者成功消费消息，消息从队列中删除。
- 消息消费失败：消费者在消费消息时发生异常，消息重新进入队列。
- 消息过期：消息在队列中存活时间超过TTL，消息过期。
- 消息进入死信队列：无法消费的消息被发送到死信队列。
📝 消息重试机制与系统监控
| 维度 | 描述 |
|---|---|
| 消息重试机制 | 当消费者消费消息失败时，可以尝试重新消费消息。 |
| 系统监控 | 监控RabbitMQ的性能和状态，确保系统稳定运行。 |
在RabbitMQ中，消息重试机制和系统监控是保证系统稳定性的关键。以下是一些常见的消息重试机制和系统监控方法：
- 消息重试机制：当消费者消费消息失败时，可以尝试重新消费消息，直到成功或达到最大重试次数。
- 系统监控：监控RabbitMQ的性能和状态，包括队列长度、消息速率、连接数等，确保系统稳定运行。
📝 性能优化
| 维度 | 描述 |
|---|---|
| 性能优化 | 通过优化队列配置、消息持久化、消费者行为等，提高RabbitMQ的性能。 |
为了提高RabbitMQ的性能，可以采取以下措施：
- 合理配置队列：根据业务需求，合理配置队列的持久化、TTL等参数。
- 优化消息持久化：合理配置消息持久化，确保消息不会因为系统故障而丢失。
- 优化消费者行为：合理配置消费者数量、消费模式等，提高消费效率。
- 系统监控与调优：监控RabbitMQ的性能和状态，根据监控结果进行调优。
通过以上分析，我们可以看出，RabbitMQ中的TTL和消息过期是一个复杂且重要的概念。在实际应用中，我们需要根据业务需求，合理配置队列、消息持久化、消费者行为等，确保消息能够被及时消费，提高系统的稳定性和性能。
🎉 RabbitMQ中的Time-To-Live（TTL）与死信队列
在RabbitMQ中，Time-To-Live（TTL）是一个非常重要的概念，它决定了消息在队列中存活的时间。当消息在队列中超过了指定的TTL时间，它就会被自动删除。这种机制可以用来处理消息过期的问题，特别是在处理大量消息时，TTL和死信队列（Dead Letter Queue，DLQ）的结合使用可以大大提高消息系统的健壮性和效率。
📝 TTL与死信队列的关系
当消息在队列中过期时，它会被放入死信队列。死信队列是一个特殊的队列，用于存储那些无法正常处理的消息。这些消息可能因为多种原因无法被消费，比如消息格式错误、队列满了、消费者处理失败等。
📝 TTL配置
在RabbitMQ中，TTL可以通过以下几种方式配置：
- 队列级别：在创建队列时，可以指定队列的TTL。
- 消息级别：在发送消息时，可以指定消息的TTL。
以下是一个队列级别TTL的配置示例：
```mermaid
graph TD
A[创建队列] --> B{设置TTL}
B --> C[队列]
C --> D[消息]
D --> E[发送]
E --> F[消息过期]
F --> G[死信队列]
#### 📝 消息持久化与重试策略
为了确保消息不会因为系统故障而丢失，我们需要对消息进行持久化。在RabbitMQ中，消息持久化可以通过以下方式实现：
- **队列持久化**：在创建队列时，设置队列的`durable`属性为`true`。
- **消息持久化**：在发送消息时，设置消息的`delivery_mode`属性为`2`。
以下是一个消息持久化的配置示例：
```mermaid
```mermaid
graph TD
A[发送消息] --> B{设置消息持久化}
B --> C[消息]
C --> D[队列持久化]
D --> E[持久化队列]
E --> F[消息存储]
对于消息重试策略，我们可以通过以下方式实现：
- **手动重试**：在消费者处理失败时，手动将消息重新发送到队列。
- **自动重试**：使用RabbitMQ的插件，如`RabbitMQ Retry`，来自动重试消息。
#### 📝 消息延迟消费与处理失败
在处理大量消息时，可能会出现消息延迟消费或处理失败的情况。为了解决这个问题，我们可以采取以下措施：
- **消息延迟消费**：使用RabbitMQ的延迟队列功能，将消息延迟一定时间后再次发送到队列。
- **消息处理失败**：在消费者处理失败时，将消息发送到死信队列，以便后续处理。
#### 📝 队列性能监控与异常处理
为了确保队列的性能和稳定性，我们需要对队列进行监控和异常处理。以下是一些监控和异常处理的措施：
- **队列性能监控**：使用RabbitMQ的监控工具，如`RabbitMQ Management Plugin`，来监控队列的性能。
- **异常处理**：在消费者处理消息时，捕获异常并进行相应的处理，如记录日志、发送报警等。
#### 📝 消息队列优化
为了提高消息队列的性能和效率，我们可以采取以下优化措施：
- **队列分区**：将队列分区可以提高消息的并发处理能力。
- **消费者负载均衡**：使用负载均衡技术，如`RabbitMQ Shovel`，将消息分发到多个消费者。
- **消息批量处理**：将多个消息合并成一个批量消息进行处理，可以提高处理效率。
通过以上措施，我们可以有效地解决RabbitMQ中TTL和死信队列消息过多的问题，提高消息系统的健壮性和效率。
## 🍊 RabbitMQ知识点之Time-To-Live：与其他消息队列对比
在许多分布式系统中，消息队列扮演着至关重要的角色，它负责在不同的服务之间传递消息和数据。然而，不同的消息队列产品在实现细节和设计理念上存在差异，这直接影响了它们在特定场景下的适用性和性能。以RabbitMQ为例，其Time-To-Live（TTL）特性允许消息在队列中存在一定时间后自动过期，这对于确保消息不会无限期地占用队列资源具有重要意义。下面，我们将通过一个场景问题引出RabbitMQ的TTL特性，并探讨其与其他消息队列产品的对比。
场景问题：在一个电商系统中，订单处理服务需要处理大量的订单消息。由于某些订单可能因为用户操作失误或其他原因被取消，这些取消的订单消息需要被及时清理，以避免占用队列资源。如果使用不支持TTL特性的消息队列，取消的订单消息可能会在队列中长时间滞留，影响系统的性能和稳定性。
介绍RabbitMQ的TTL特性：RabbitMQ的TTL特性允许为队列或消息设置一个过期时间。当消息到达队列后，如果在该时间之前没有被消费者消费，它将被自动删除。这种机制有助于防止消息队列中的数据无限增长，提高系统的可维护性和性能。
需要介绍RabbitMQ知识点之Time-To-Live：与其他消息队列对比的原因在于，了解不同消息队列产品的TTL实现方式可以帮助开发人员根据实际需求选择最合适的解决方案。例如，Kafka和ActiveMQ等消息队列产品也支持TTL特性，但它们在实现细节上有所不同。
接下来，我们将分别对比RabbitMQ的TTL特性与Kafka、ActiveMQ的TTL特性。在RabbitMQ知识点之Time-To-Live：与Kafka对比中，我们将探讨RabbitMQ和Kafka在TTL设置、过期消息处理等方面的异同。而在RabbitMQ知识点之Time-To-Live：与ActiveMQ对比中，我们将分析RabbitMQ和ActiveMQ在TTL配置、过期策略等方面的区别。
通过对比分析，读者可以更全面地了解不同消息队列产品的TTL特性，从而在设计和实现分布式系统时，能够根据实际需求做出合理的选择。
### 🎉 RabbitMQ Time-To-Live 与 Kafka 过期机制
在消息队列领域，RabbitMQ 和 Kafka 都是常用的解决方案。它们各自有不同的过期机制，即 Time-To-Live（TTL）配置。下面，我们将对比 RabbitMQ 和 Kafka 的 TTL 配置，并探讨它们在消息过期处理、消息延迟队列、消息持久化、消息可靠性、系统性能优化、集群部署策略、故障恢复机制以及应用场景等方面的差异。
#### 📝 TTL配置对比
| 特性 | RabbitMQ TTL | Kafka TTL |
| --- | --- | --- |
| **配置方式** | 在队列或消息级别设置 | 在主题级别设置 |
| **时间单位** | 毫秒 | 秒 |
| **过期处理** | 消息过期后，根据队列策略进行丢弃或重新入队 | 消息过期后，根据配置策略进行丢弃或保留 |
| **消息延迟队列** | 支持消息延迟队列功能 | 不支持消息延迟队列功能，但可以通过其他方式实现 |
#### 📝 消息过期处理
在 RabbitMQ 中，当消息过期时，根据队列的过期策略，消息可能会被丢弃或重新入队。而在 Kafka 中，消息过期后，根据配置策略，消息可能会被丢弃或保留。
| RabbitMQ | Kafka |
| --- | --- |
| **丢弃** | **丢弃** |
| **重新入队** | **保留** |
#### 📝 消息延迟队列
RabbitMQ 支持消息延迟队列功能，可以通过设置消息的 TTL 来实现。而 Kafka 不支持消息延迟队列功能，但可以通过其他方式实现，如使用 Kafka Connect 和外部存储系统。
#### 📝 消息持久化
RabbitMQ 和 Kafka 都支持消息持久化，确保消息不会因为系统故障而丢失。
| RabbitMQ | Kafka |
| --- | --- |
| **支持** | **支持** |
#### 📝 消息可靠性
RabbitMQ 和 Kafka 都提供了高可靠性的保障，确保消息的准确传递。
| RabbitMQ | Kafka |
| --- | --- |
| **可靠性** | **可靠性** |
#### 📝 系统性能优化
RabbitMQ 和 Kafka 在系统性能优化方面各有特点。RabbitMQ 适用于低延迟、高并发的场景，而 Kafka 适用于高吞吐量的场景。
| RabbitMQ | Kafka |
| --- | --- |
| **低延迟、高并发** | **高吞吐量** |
#### 📝 集群部署策略
RabbitMQ 和 Kafka 都支持集群部署，提高系统的可用性和扩展性。
| RabbitMQ | Kafka |
| --- | --- |
| **集群部署** | **集群部署** |
#### 📝 故障恢复机制
RabbitMQ 和 Kafka 都提供了故障恢复机制，确保系统在发生故障时能够快速恢复。
| RabbitMQ | Kafka |
| --- | --- |
| **故障恢复** | **故障恢复** |
#### 📝 应用场景对比
| 场景 | RabbitMQ | Kafka |
| --- | --- | --- |
| **实时消息处理** | 适合 | 适合 |
| **日志收集** | 适合 | 适合 |
| **事件驱动架构** | 适合 | 适合 |
| **消息队列** | 适合 | 适合 |
总结来说，RabbitMQ 和 Kafka 在 TTL 配置、消息过期处理、消息延迟队列、消息持久化、消息可靠性、系统性能优化、集群部署策略、故障恢复机制以及应用场景等方面存在差异。在实际应用中，应根据具体需求选择合适的消息队列解决方案。
### 🎉 RabbitMQ Time-To-Live 与 ActiveMQ TTL 对比
在消息队列领域，RabbitMQ 和 ActiveMQ 是两款非常流行的消息中间件。它们都提供了消息过期功能，即 Time-To-Live（TTL）。下面，我们将从多个维度对比 RabbitMQ 的 TTL 与 ActiveMQ 的 TTL。
#### 📝 RabbitMQ TTL 配置
RabbitMQ 的 TTL 配置非常灵活，可以在多个级别进行设置：
- **队列级别**：在创建队列时，可以指定队列的 TTL。
- **消息级别**：在发送消息时，可以指定消息的 TTL。
以下是一个 RabbitMQ 队列和消息 TTL 的配置示例：
```java
// 队列 TTL 配置
channel.queueDeclare("queue_name", true, false, false, new HashMap<String, Object>() {{
put("x-message-ttl", 60000); // 60秒
}});
// 消息 TTL 配置
BasicProperties props = new BasicProperties.Builder()
.expiration("60000") // 60秒
.build();
channel.basicPublish("", "queue_name", props, message.getBytes());
📝 ActiveMQ TTL 配置
ActiveMQ 的 TTL 配置相对简单，只能在队列级别进行设置：
Queue queue = session.createQueue("queue_name");
QueueBrowser browser = session.createBrowser(queue);
for (Message message : browser) {
// 处理消息
}
在 ActiveMQ 中，可以通过队列的 getTTL() 方法获取队列的 TTL。
📝 消息过期策略
RabbitMQ 和 ActiveMQ 都提供了消息过期策略：
- RabbitMQ：当消息过期时，RabbitMQ 会将消息从队列中移除，并触发一个死信队列（Dead Letter Queue）。
- ActiveMQ：当消息过期时，ActiveMQ 会将消息从队列中移除，并可以选择将消息发送到另一个队列或丢弃。
以下是一个 RabbitMQ 死信队列的配置示例：
channel.exchangeDeclare("exchange_name", "direct", true);
channel.queueDeclare("queue_name", true, false, false, new HashMap<String, Object>() {{
put("x-dead-letter-exchange", "exchange_name");
}});
channel.queueBind("queue_name", "exchange_name", "routing_key");
📝 消息过期处理
RabbitMQ 和 ActiveMQ 都提供了消息过期处理机制：
- RabbitMQ：可以通过监听死信队列来处理过期的消息。
- ActiveMQ：可以通过监听过期队列来处理过期的消息。
以下是一个 RabbitMQ 监听死信队列的示例：
channel.basicConsume("dead_letter_queue", false, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
// 处理过期的消息
}
});
📝 消息延迟队列
RabbitMQ 和 ActiveMQ 都支持消息延迟队列：
- RabbitMQ：可以通过消息的 TTL 实现延迟队列。
- ActiveMQ：可以通过延迟消息插件实现延迟队列。
以下是一个 RabbitMQ 延迟队列的示例：
BasicProperties props = new BasicProperties.Builder()
.expiration("60000") // 60秒后发送
.build();
channel.basicPublish("", "queue_name", props, message.getBytes());
📝 消息过期通知
RabbitMQ 和 ActiveMQ 都支持消息过期通知：
- RabbitMQ：可以通过死信队列监听消息过期通知。
- ActiveMQ：可以通过过期队列监听消息过期通知。
以下是一个 RabbitMQ 监听消息过期通知的示例：
channel.basicConsume("dead_letter_queue", false, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
// 处理过期的消息
}
});
📝 系统性能影响
RabbitMQ 和 ActiveMQ 的 TTL 配置对系统性能的影响如下：
- RabbitMQ：合理配置 TTL 可以提高系统性能，避免消息堆积。
- ActiveMQ：合理配置 TTL 可以减少内存占用，提高系统性能。
📝 应用场景对比
RabbitMQ 和 ActiveMQ 的 TTL 应用场景如下：
- RabbitMQ：适用于需要精确控制消息生命周期的场景，如订单处理、任务调度等。
- ActiveMQ：适用于需要简单消息过期功能的场景，如日志收集、监控等。
📝 配置优化建议
- RabbitMQ：合理配置队列和消息的 TTL，避免消息堆积。
- ActiveMQ：合理配置队列的 TTL，减少内存占用。
📝 跨平台兼容性
RabbitMQ 和 ActiveMQ 都具有较好的跨平台兼容性。
📝 社区支持与文档
RabbitMQ 和 ActiveMQ 都拥有活跃的社区和丰富的文档资源。
📝 最佳实践
- RabbitMQ：合理配置 TTL，避免消息堆积。
- ActiveMQ：合理配置 TTL，减少内存占用。
通过以上对比，我们可以看出 RabbitMQ 和 ActiveMQ 的 TTL 在配置、消息过期策略、消息过期处理、消息延迟队列、消息过期通知、系统性能影响、应用场景、配置优化建议、跨平台兼容性、社区支持与文档等方面各有特点。在实际应用中，应根据具体需求选择合适的消息中间件。
博主分享
📥博主的人生感悟和目标
📙经过多年在优快云创作上千篇文章的经验积累，我已经拥有了不错的写作技巧。同时，我还与清华大学出版社签下了四本书籍的合约，并将陆续出版。
- 《Java项目实战—深入理解大型互联网企业通用技术》基础篇的购书链接：https://item.jd.com/14152451.html
- 《Java项目实战—深入理解大型互联网企业通用技术》基础篇繁体字的购书链接：http://product.dangdang.com/11821397208.html
- 《Java项目实战—深入理解大型互联网企业通用技术》进阶篇的购书链接：https://item.jd.com/14616418.html
- 《Java项目实战—深入理解大型互联网企业通用技术》架构篇待上架
- 《解密程序员的思维密码--沟通、演讲、思考的实践》购书链接：https://item.jd.com/15096040.html
面试备战资料
八股文备战
| 场景 | 描述 | 链接 |
|---|---|---|
| 时间充裕（25万字） | Java知识点大全（高频面试题） | Java知识点大全 |
| 时间紧急（15万字） | Java高级开发高频面试题 | Java高级开发高频面试题 |
理论知识专题（图文并茂，字数过万）
| 技术栈 | 链接 |
|---|---|
| RocketMQ | RocketMQ详解 |
| Kafka | Kafka详解 |
| RabbitMQ | RabbitMQ详解 |
| MongoDB | MongoDB详解 |
| ElasticSearch | ElasticSearch详解 |
| Zookeeper | Zookeeper详解 |
| Redis | Redis详解 |
| MySQL | MySQL详解 |
| JVM | JVM详解 |
集群部署（图文并茂，字数过万）
| 技术栈 | 部署架构 | 链接 |
|---|---|---|
| MySQL | 使用Docker-Compose部署MySQL一主二从半同步复制高可用MHA集群 | Docker-Compose部署教程 |
| Redis | 三主三从集群（三种方式部署/18个节点的Redis Cluster模式） | 三种部署方式教程 |
| RocketMQ | DLedger高可用集群（9节点） | 部署指南 |
| Nacos+Nginx | 集群+负载均衡（9节点） | Docker部署方案 |
| Kubernetes | 容器编排安装 | 最全安装教程 |
开源项目分享
| 项目名称 | 链接地址 |
|---|---|
| 高并发红包雨项目 | https://gitee.com/java_wxid/red-packet-rain |
| 微服务技术集成demo项目 | https://gitee.com/java_wxid/java_wxid |
管理经验
【公司管理与研发流程优化】针对研发流程、需求管理、沟通协作、文档建设、绩效考核等问题的综合解决方案：https://download.youkuaiyun.com/download/java_wxid/91148718
希望各位读者朋友能够多多支持！
现在时代变了，信息爆炸，酒香也怕巷子深，博主真的需要大家的帮助才能在这片海洋中继续发光发热，所以，赶紧动动你的小手，点波关注❤️，点波赞👍，点波收藏⭐，甚至点波评论✍️，都是对博主最好的支持和鼓励！
- 💂 博客主页： Java程序员廖志伟
- 👉 开源项目：Java程序员廖志伟
- 🌥 哔哩哔哩：Java程序员廖志伟
- 🎏 个人社区：Java程序员廖志伟
- 🔖 个人微信号：
SeniorRD
🔔如果您需要转载或者搬运这篇文章的话，非常欢迎您私信我哦~
扫一扫
969
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
