alter

Author: Lysssyo

_posts/2024-08-24-MessageQueue.md

@@ -847,6 +847,8 @@ spring:
 
    在控制台的`Exchanges`页面，添加交换机时可以配置交换机的`Durability`参数：
 
+   设置 `durable=true`，表示**RabbitMQ 重启后交换机仍然存在**，不会丢失。
+
    <img src="/assets/MessageQueue.assets/image-20240821211201804.png" alt="image-20240821211201804" style="zoom:50%;">
 
    > SpringAMQP创建的交换机默认持久化
@@ -868,6 +870,8 @@ spring:
 
 2. **队列持久化**
 
+   设置 `durable=true`，表示**RabbitMQ 重启后队列还存在**（队列结构保留），不会丢失。
+
    SpringAMQP创建的队列默认持久化
 
    ```java
@@ -903,8 +907,10 @@ spring:
 
 3. **消息持久化**
 
-   SpringAMQP创建的消息默认持久化
+   消息在发送时，设置 `deliveryMode=2`（持久化模式），表示消息会**写入磁盘**，即使 RabbitMQ 异常宕机也能恢复。
 
+   SpringAMQP创建的消息默认持久化
+   
    ```java
        @Test
        public void testSendMap() throws InterruptedException {
@@ -916,7 +922,7 @@ spring:
            rabbitTemplate.convertAndSend("object3.queue", msg);
        }
    ```
-
+   
    <img src="/assets/MessageQueue.assets/image-20240821211717209.png" alt="image-20240821211717209" style="zoom:67%;">
 
 #### 4.2.2 LazyQueue
@@ -1145,7 +1151,7 @@ spring:
 
 <img src="/assets/MessageQueue.assets/image-20240824155020808.png" alt="image-20240824155020808" style="zoom:80%;">
 
-当然，上述极端情况发生的概率还是非常低的，不过不怕一万就怕万一。为了应对上述情况Spring又提供了消费者失败重试机制：在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。
+当然，上述极端情况发生的概率还是非常低的，不过不怕一万就怕万一。为了应对上述情况Spring又提供了**消费者失败重试机制：在消费者出现异常时利用本地重试**，而不是无限制的requeue到mq队列。
 
 ```yaml
 spring:
@@ -1283,7 +1289,25 @@ spring:
 - 开启消费者确认机制为auto，由spring确认消息处理成功后返回ack，异常时返回nack
 - 或者开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理
 
-### 4.4 业务幂等性处理
+### 4.4 兜底方案
+
+核心在于**主动查询**。
+
+例如：既然MQ通知不一定发送到交易服务，那么交易服务就必须自己**主动去查询**支付状态。这样即便支付服务的MQ通知失败，我们依然能通过主动查询来保证订单状态的一致。
+
+<img src="/assets/MessageQueue.assets/image-20240824165411656.png" alt="image-20240824165411656" style="zoom:80%;">
+
+> 那么问题来了，我们到底该在什么时间主动查询支付状态呢？
+>
+> 这个时间是无法确定的，因此，通常我们采取的措施就是利用**定时任务**定期查询，例如每隔20秒就查询一次，并判断支付状态。如果发现订单已经支付，则立刻更新订单状态为已支付即可。
+
+综上，支付服务与交易服务之间的订单状态一致性是如何保证的？
+
+- 首先，支付服务会正在用户支付成功以后利用MQ消息通知交易服务，完成订单状态同步。
+- 其次，为了保证MQ消息的可靠性，我们采用了生产者确认机制、消费者确认、消费者失败重试等策略，确保消息投递的可靠性
+- 最后，我们还在交易服务设置了定时任务，定期查询订单支付状态。这样即便MQ通知失败，还可以利用定时任务作为兜底方案，确保订单支付状态的最终一致性。
+
+## 5. 业务幂等性处理
 
 何为幂等性？
 
@@ -1309,7 +1333,7 @@ spring:
 - 唯一消息ID
 - 业务状态判断
 
-#### 4.4.1 唯一消息ID
+### 5.1 唯一消息ID
 
 思路：
 
@@ -1338,7 +1362,7 @@ public MessageConverter messageConverter(){
 
 > 意思就是，SpringAMOP帮你写好了新建MessageId的代码，但是利用MessageId实现业务幂等需要自己写
 
-#### 4.4.2 业务判断
+### 5.2 业务判断
 
 业务判断就是基于业务本身的逻辑或状态来判断是否是重复的请求或消息，不同的业务场景判断的思路也不一样。
 
@@ -1365,23 +1389,7 @@ public MessageConverter messageConverter(){
     }
 ```
 
-### 4.5 兜底方案
-
-核心在于**主动查询**。
-
-例如：既然MQ通知不一定发送到交易服务，那么交易服务就必须自己**主动去查询**支付状态。这样即便支付服务的MQ通知失败，我们依然能通过主动查询来保证订单状态的一致。
-
-<img src="/assets/MessageQueue.assets/image-20240824165411656.png" alt="image-20240824165411656" style="zoom:80%;">
 
-> 那么问题来了，我们到底该在什么时间主动查询支付状态呢？
->
-> 这个时间是无法确定的，因此，通常我们采取的措施就是利用**定时任务**定期查询，例如每隔20秒就查询一次，并判断支付状态。如果发现订单已经支付，则立刻更新订单状态为已支付即可。
-
-综上，支付服务与交易服务之间的订单状态一致性是如何保证的？
-
-- 首先，支付服务会正在用户支付成功以后利用MQ消息通知交易服务，完成订单状态同步。
-- 其次，为了保证MQ消息的可靠性，我们采用了生产者确认机制、消费者确认、消费者失败重试等策略，确保消息投递的可靠性
-- 最后，我们还在交易服务设置了定时任务，定期查询订单支付状态。这样即便MQ通知失败，还可以利用定时任务作为兜底方案，确保订单支付状态的最终一致性。
 
 ## 5. 延迟信息