RabbitMQ消息持久化、消息确认、消息重试、死信队列实战！

野性酷女 2022-10-22 07:47 93阅读 0赞

不知各位小伙伴是否听闻过：MQ消息持久化、消息的确认机制、消息的重试机制和死信队列这几个名词啊，如果没听说过的小伙伴可就要去好好补补课啦！  
微信搜索：“每日一试” 或 “每日一面”关注公众号，每日收集大厂面试真题，每天学习新知识！  
或者扫描下方二维码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70]

既然听说过，那你们可知这些又是如何实现的呢？  
闲话不多说，接下来咱们进行实战！

#### 1. 配置环境： ####

①安装Erlang环境包  
②RabbitMQ官网：http://www.rabbitmq.com/  
下载RabbitMQ软件包并安装，此文就不再一一赘述了

> ps：若是需要以上详细安装步骤的可关注公众号留言

#### 2. 编写SpringBoot测试模块 ####

①新建SpringBoot项目  
②pom.xml添加依赖

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-amqp</artifactId>
    </dependency>
    
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

③yml配置文件  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 1]

④编写启动类

@SpringBootApplication
    public class ApiApplication { 
    
        public static void main(String[] args) { 
            SpringApplication.run(ApiApplication.class, args);
        }
    
    }

#### 3. 消息的持久化 ####

##### 3.1配置类：FanoutCongif.java #####

创建一个队列：

@Bean
    public Queue createQueue() { 
        Queue queue = new Queue("test_queue", true, false, false, null);
        return queue;
    }

Queue构造方法有五个参数

*  第一个参数：队列名称
 *  第二个参数：是否持久化，false对应不持久化数据，MQ停掉数据就会丢失，此参数默认是true，即默认持久化
 *  第三个参数：是否队列私有化，false则表示所有的消费者都可以访问，true代表只有第一次拥有它的消费者才能一直使用
 *  第四个参数：是否自动删除，false代表连接停掉后不会自动删除这个队列
 *  其他参数设置

创建一个交换机：

@Bean
    public FanoutExchange createExchange() { 
        FanoutExchange fanoutExchange = new FanoutExchange("test_fanoutExchange", true, false, null);
        return fanoutExchange;
        }

Exchange构造方法参数与Queue一样。

声明交换机与队列的绑定关系：

@Bean
    public Binding createBinding() { 
        return BindingBuilder.bind(createQueue()).to(createExchange());
    }

启动项目，会自动帮我们创建交换机以及队列

> 交换机、队列持久化：即MQ服务器关闭或者重启之后，交换机依然存在，队列以及队列中未曾被消费的数据依然存在

###### 3.1.1 持久化验证 ######

①通过RabbitMQ的控制台：localhost:15672登录查看  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 3]  
②进入到RabbitMQ的sbin目录，使用cmd命令：使用rabbitmqctl.bat list\_queues命令查看队列以及队列的消息数量  
![在这里插入图片描述][2021040515263080.png]

##### 3.2 消息生产者及消费者 #####

消息生产者：RabbitProducerController.java

@Autowired
    private RabbitTemplate rabbitTemplate;
    
    @GetMapping("/sendMes")
    public String sendMes(String msg) { 
        rabbitTemplate.convertAndSend("test_fanoutExchange", "test_queue", msg, message -> { 
                    message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                    return message;
                },
                new CorrelationData(UUID.randomUUID().toString()));
    // rabbitTemplate.convertAndSend("test_fanoutExchange", "test_queue", msg);// 使用此代码也可发送消息
        log.info("生产消息:{}", msg);
        return "生产消息：" + msg;
    }

消息消费者：

@RabbitListener(queues = "test_queue")
    // @RabbitHandler
    public void consumer(String msg, Channel channel, Message message) throws IOException { 
        log.info("消费消息：{}", msg);
    }

###### 3.2.1 测试： ######

使用浏览器或postman发送消息，可以看到后台输出日志，表名我们的消息已经生产并且被消费了  
![在这里插入图片描述][20210405154459191.png]  
MQ可视化后台查看：可以看到，队列中没有消息，因为已经消费完了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 4]

> ps：消息消费完了之后自动删除，是因为RabbitMQ默认是使用的自动确认机制，可以改为手动确认机制↓

##### 4. 消息确认机制 #####

我们知道RabbitMQ的消息确认机制有

*  生产者—>Exchange（生产者）
 *  Exchange—>Queue（生产者）
 *  消费者ACK(manual：手动确认 auto：自动确认(默认) none：不确认)

在yml配置文件添加代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 5]  
好，此时我们重启项目，再次生产一条消息：  
![在这里插入图片描述][20210405160046352.png]  
可以看到我们的消费者依然是正常的消费了消息，但是不要高兴的太早…我们来到控制台：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 6]  
我K，为什么这里还是显示有一条消息，我明明已经消费了的啊，为什么还有…别急，这个时候我们再来重启一下项目：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 7]  
WTF？又消费一次？这不就导致消息重复消费了吗？苍天啊…

别慌别慌，James来解答各位的疑惑，出现这种情况呢是因为我们刚才在yml配置文件将消息的确认机制改为了自动确认，而我们在消费者中并没有添加与确认相关的任何代码，我们改造一下生产者和消费者↓  
生产者：RabbitProducerController.java

@Autowired
    private RabbitTemplate rabbitTemplate;
    @Autowired
    private ConfirmCallbackService confirmCallbackService;
    @Autowired
    private ReturnCallbackService returnCallbackService;
    
    
    @GetMapping("/sendMes")
    public String sendMes(String msg) { 
        /** * 确保消息发送失败后可以重新返回到队列中 * 注意：yml需要配置 publisher-returns: true */
        rabbitTemplate.setMandatory(true);
        /** * 消费者确认收到消息后，手动ack回执回调处理 */
        rabbitTemplate.setConfirmCallback(confirmCallbackService);
        /** * 消息投递到队列失败回调处理 */
        rabbitTemplate.setReturnCallback(returnCallbackService);
        rabbitTemplate.convertAndSend("test_fanoutExchange", "test_queue", msg, message -> { 
                    message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                    return message;
                },
                new CorrelationData(UUID.randomUUID().toString()));
    // rabbitTemplate.convertAndSend("test_fanoutExchange", "test_queue", msg);
        log.info("生产消息:{}", msg);
        return "生产消息：" + msg;
    }

Confirm确认回调：ConfirmCallbackService.java  
交换机确认收到消息后，手动ack回执回调处理 yml需要设置publisher-confirms: true

/** * 交换机确认收到消息后，手动ack回执回调处理 yml需要设置publisher-confirms: true */
    @Slf4j
    @Component
    public class ConfirmCallbackService implements RabbitTemplate.ConfirmCallback { 
        @Override
        public void confirm(CorrelationData correlationData, boolean ack, String cause) { 
            if (ack) { 
                log.info("交换机已经确认收到，correlationData={} ,ack={}, cause={}", correlationData.getId(), ack);
            } else { 
                log.error("消息发送异常!:{}", cause);
            }
        }
    }

confirm方法参数详解：

*  correlationData：对象内部只有一个 id 属性，用来表示当前消息的唯一性。
 *  ack：消息投递到broker 的状态，true表示成功。
 *  cause：表示投递失败的原因。

Return确认回调：ReturnCallbackService.java  
消息投递到队列失败回调处理

/** * 消息投递到队列失败回调处理 */
    @Slf4j
    @Component
    public class ReturnCallbackService implements RabbitTemplate.ReturnCallback{ 
        @Override
        public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) { 
            log.info("returnedMessage ===> replyCode={} ,replyText={} ,exchange={} ,routingKey={}", replyCode, replyText, exchange, routingKey);
        }
    }

returnedMessage方法参数详解：

*  message（消息体）
 *  replyCode（响应code）
 *  replyText（响应内容）
 *  exchange（交换机）
 *  routingKey（队列）

消息消费者：

/** * 消费消息有三种回执方法，我们来分析一下每种方法的含义。 * @param msg * @param channel * @param message * @throws IOException */
    @RabbitListener(queues = "test_queue")
    //@RabbitHandler
    public void consumer(String msg, Channel channel, Message message) throws IOException { 
        try { 
    // int i = 10/0;
            log.info("消费消息：{}", msg);
                
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), true);
    
        }  catch (Exception e) { 
    
            if (message.getMessageProperties().getRedelivered()) { 
    
                log.error("消息已重复处理失败,拒绝再次接收...");
                
                channel.basicReject(message.getMessageProperties().getDeliveryTag(), false); // 拒绝消息
            } else { 
    
                log.error("消息即将再次返回队列处理...");
                channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
            }
        }
    }

在consumer方法添加：channel(信道)、message 两个参数。

消费消息有三种回执方法，我们来分析一下每种方法的含义。

**1、basicAck**  
basicAck：表示成功确认，使用此回执方法后，消息会被rabbitmq broker 删除。

void basicAck(long deliveryTag, boolean multiple)

*  deliveryTag：表示消息投递序号，每次消费消息或者消息重新投递后，deliveryTag都会增加。手动消息确认模式下，我们可以对指定deliveryTag的消息进行ack、nack、reject等操作。
 *  multiple：是否批量确认，值为 true 则会一次性 ack所有小于当前消息 deliveryTag 的消息。

> 举个梨子： 假设我先发送三条消息deliveryTag分别是5、6、7，可它们都没有被确认，当我发第四条消息此时deliveryTag为8，multiple设置为 true，会将5、6、7、8的消息全部进行确认。

**2、basicNack**  
basicNack ：表示失败确认，一般在消费消息业务异常时用到此方法，可以将消息重新投递入队列。

void basicNack(long deliveryTag, boolean multiple, boolean requeue)

*  deliveryTag：表示消息投递序号。
 *  multiple：是否批量确认。
 *  requeue：值为 true 消息将重新入队列。

**3、basicReject**  
basicReject：拒绝消息，与basicNack区别在于不能进行批量操作，其他用法很相似。

void basicReject(long deliveryTag, boolean requeue)

*  deliveryTag：表示消息投递序号。
 *  requeue：值为 true 消息将重新入队列。

###### 4.1 消息确认机制的测试 ######

好了，我们现在重启一下项目，再次生产一条消息：  
![在这里插入图片描述][20210405164400973.png]  
可以看到，我们的消息已经正常投递到Exchange、Queue和正常消费了，我们看一下控制台：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 8]  
可以看到消息也已经被删除了，ok，一切正常，完美！

##### 5. 消息重试 #####

yml配置文件：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 9]  
修改一下消费者，手动抛出一个异常，因为消息若是被正常消费那肯定不需要重试了：

@RabbitListener(queues = "test_queue")
    //@RabbitHandler
    public void consumer(String msg, Channel channel, Message message) throws IOException { 
        try { 
            int i = 10/0;
            log.info("消费消息：{}", msg);
                
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), true);
    
        }  catch (Exception e) { 
    
            if (message.getMessageProperties().getRedelivered()) { 
    
                log.error("消息已重复处理失败,拒绝再次接收...");
                
                channel.basicReject(message.getMessageProperties().getDeliveryTag(), false); // 拒绝消息
            } else { 
    
                log.error("消息即将再次返回队列处理...");
                channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
            }
        }
    }

ok，重新启动，生产一条消息，通过断点我们发现，消息并没有像我们配置文件中配置的那样重试3次，这是怎么回事呢？

是这样的，在我们的消费者中可以看到我将异常给try、catch起来了，那么这样的话呢，我们的异常被自己捕获那就不算异常了，我们来修改一下消费者：

@RabbitListener(queues = "test_queue")
    // @RabbitHandler
    public void consumer(String msg, Channel channel, Message message) throws IOException { 
            int i = 10/0;
            log.info("消费消息：{}", msg);
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), true);
    }

这样我们通过断点可以发现我们的int i = 10/0;这样代码执行了3次。

> PS：消息的重试也可以通过使用第三方的中间件，例如Redis、MongoDB来记录当前已经重试的次数↓

> 思考：即使重试了3次，可是代码还是出现异常，那怎么办？↓

@RabbitHandler
    public void processHandler(String msg, Channel channel, Message message) throws IOException { 
    
        try { 
    	    int a = 1 / 0;
            log.info("消费消息：{}", msg);
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
    
        } catch (Exception e) { 
    
            channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
        }
    }

出现了异常那就让消息重新回到队列里面，然后再次消费，是不是以为这是一个好办法？不…这样会死人的↓

> 在生产上，代码出现问题，99%是不会自动修复的，一条消息会被无限投递进队列，消费端无限执行，导致了死循环。CPU瞬间打满，生产服务器直接挂掉…

经过测试分析发现，当消息重新投递到消息队列时，这条消息不会回到队列尾部，仍是在队列头部。

消费者会立刻消费这条消息，业务处理再抛出异常，消息再重新入队，如此反复进行。导致消息队列处理出现阻塞，导致正常消息也无法运行。

这个怎么解决？

我们可以先对消息进行确认，然后再将异常的消息重新发送到队列，这样的话，这条消息就会出现在队列的尾部。

channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
    // 重新发送消息到队尾
    // 参数：Exchange、routingKey、额外的设置属性、消息字节数组
    channel.basicPublish(message.getMessageProperties().getReceivedExchange(),
            message.getMessageProperties().getReceivedRoutingKey(),
            null,
            JSON.toJSONBytes(msg));

但是这样也不是办法，这条消息还是会失败…

解答：这个时候我们可以借助MySQL或Redis等将消息持久化到数据库进行人工处理…

##### 6. 死信队列 #####

当我们设置的消息重试次数超过了之后，会将此消息转发到死信队列！  
修改我们的Queue，配置类：FanoutCongif.java

*  给队列增加x-dead-letter-exchange和x-dead-letter-routing-key参数，用于指定死信队列的路由和routingKey
 *  创建死信队列
 *  创建死信交换机
 *  绑定死信交换机与死信队列的关系

@Bean
    public Queue createQueue() { 
        // 给队列增加x-dead-letter-exchange和x-dead-letter-routing-key参数，用于指定死信队列的路由和routingKey
        Map<String, Object> args = new HashMap<String, Object>();
        args.put("x-dead-letter-exchange", "test_dead_letter_Exchange");
        args.put("x-dead-letter-routing-key", "test_dead_letter_.#");
        Queue queue = new Queue("test_queue", true, false, false, args );
        return queue;
    }
    
    // ========== dead_letter =============
    @Bean
    public Queue createDeadLetterQueue() { 
        return new Queue("test_dead_letter_queue", false, false, false, null);
    }
    
    @Bean
    public FanoutExchange createDeadLetterExchange() { 
        FanoutExchange fanoutExchange = new FanoutExchange("test_dead_letter_exchange", true, false, null);
        return fanoutExchange;
    }
    
    @Bean
    public Binding createDeadLetterBinding() { 
        return BindingBuilder.bind(createDeadLetterQueue()).to(createDeadLetterExchange());
    }

配置MessageRecoverer对异常消息进行处理，此处理会在listener.retry次数尝试完并还是抛出异常的情况下才会调用  
若不加此配置，则会默认使用：RejectAndDontRequeueRecoverer.java，实现仅仅是将异常打印抛出

// 配置MessageRecoverer对异常消息进行处理，此处理会在listener.retry次数尝试完并还是抛出异常的情况下才会调用
    // 若不加此配置，则会默认使用：RejectAndDontRequeueRecoverer.java，实现仅仅是将异常打印抛出
    @Bean
    public MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate){ 
        return new RepublishMessageRecoverer(rabbitTemplate, "test_dead_letter_exchange", "test_dead_letter_.#");
    }

创建一个死信队列的消费者：

@Slf4j
    @Component
    @RabbitListener(queues = "test_dead_letter_queue")
    public class ConsumerController { 
    
        @RabbitHandler
        public void consumer(String msg, Channel channel, Message message) throws IOException { 
            log.info("欢迎来到死信队列！msg:{}", msg);
            // TODO 由于设置了消息手动确认机制，故此，需要手动ACK，否则死信队列里面的消息会一直存在->重复消费
            // channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
        }
    }

启动项目，生产一条消息，查看日志：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 10]

可以看到，消息重试了三次，还是失败后进入了死信队列…

那么在死信队列里面可以对我们的异常消息进行MySQL\\Redis持久化，然后人工处理等等操作…

好啦，今天的分享就到这里啦，不知道对小伙伴们有没有帮助呢？  
喜欢的同学可以  
微信搜索：“每日一试” 或 “每日一面”关注公众号，每日收集大厂面试真题，每天学习新知识！  
或者扫描下方二维码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70]

创作不易，多多关照！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70]: /images/20221022/66ab81fc64364d28b153a960faec3a3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 1]: /images/20221022/fe12314aa643400eaa4377ed8db9d092.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 2]: /images/20221022/4c813632143241c385b802c7dee5cb31.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 3]: /images/20221022/0d0822d1aabf4cc092ebc1d6318b9e3e.png
[2021040515263080.png]: /images/20221022/9fb028cf80db44c2aa95a4267646ebeb.png
[20210405154459191.png]: /images/20221022/db77b89bd17a481ea42424a0d05f7341.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 4]: /images/20221022/079bc5119678412eb7c1ead622c5093a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 5]: /images/20221022/59f3177231614cf6bef73f5f6c08d44a.png
[20210405160046352.png]: /images/20221022/057daca78e7c40589fe9e1eaab259515.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 6]: /images/20221022/498210a685fb449c8ff5c91b579351b9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 7]: /images/20221022/3c1d193096d14e32a3f79a3fc0b12867.png
[20210405164400973.png]: /images/20221022/ab2b1d9f48864850a37507037653ddba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 8]: /images/20221022/457cff3297be4c30bf1c792b5207a495.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 9]: /images/20221022/c74b50c1b919423f84362c64d0cb424f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 10]: /images/20221022/75c60cac676147b2975432bbb7c24fc1.png