服务异步通信-高级篇(RabbitMQ)

这篇具有很好参考价值的文章主要介绍了服务异步通信-高级篇(RabbitMQ)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1. 消息可靠性

服务异步通信-高级篇(RabbitMQ),java,运维

每一步都可能导致消息丢失,常见的丢失原因包括:

  • 发送时丢失:
    • 生产者发送的消息未送达exchange
    • 消息到达exchange后未到达queue
  • MQ宕机,queue将消息丢失
  • consumer接收到消息后未消费就宕机

RabbitMQ分别给出了解决方案:

  • 生产者发送确认机制
  • mq持久化
  • 消费者消费确认机制
  • 失败重试机制

1.1. 生产者消息确认

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。

这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后,会返回一个结果给发送者,表示消息是否处理成功。

返回结果有两种方式:

  • publisher-confirm,发送者确认
    • 消息成功投递到交换机,返回ack
    • 消息未投递到交换机,返回nack
  • publisher-return,发送者回执
    • 消息投递到交换机了,但是没有路由到队列。返回ACK,及路由失败原因。

注意:确认机制在发送消息时,需要给每个消息设置一个全局唯一的id,以区分不同的消息,避免ack冲突

服务异步通信-高级篇(RabbitMQ),java,运维

1.1.1. 修改配置

修改publisher服务中的application.yml文件,添加下面的内容:

spring:
  rabbitmq:
    # 启用发送者确认,生产者到交换机
    publisher-confirm-type: correlated
    # 启用发送者确认,从交换机到队列
    publisher-returns: true
  	# 启用失败的回调
    template:
      mandatory: true

说明:

  • publish-confirm-type:开启publisher-confirm,这里支持两种类型:
    • simple:同步等待confirm结果,直到超时
    • correlated:异步回调,定义ConfirmCallback,MQ返回结果时会回调这个ConfirmCallback
  • publish-returns:开启publish-return功能,同样是基于callback机制,不过是定义ReturnCallback
  • template.mandatory:定义消息路由失败时的策略。true,则调用ReturnCallback;false:则直接丢弃消息

1.1.2. 定义ConfirmCallback

对发送者把消息发送到交换机进行确认

在发送消息时指定

@Test
    public void test() throws InterruptedException {
        String exchanges = "itcast.direct";
        String routingKey = "phone";
        String message = "hello, spring amqp!";
        CorrelationData correlation = new CorrelationData(UUID.randomUUID().toString());
        //发送的通知回调
        correlation.getFuture().addCallback(new ListenableFutureCallback<CorrelationData.Confirm>() {
            @Override
            public void onFailure(Throwable ex) {
                log.error("消息发送异常",ex);
            }
            //生产者正常把消息发出来了
            @Override
            public void onSuccess(CorrelationData.Confirm result) {
                boolean ack = result.isAck();
                if (ack){
                    log.info("交换正常收到消息");
                }else {
                    log.info("交换机没有收到消息");
                }
            }
        });
        rabbitTemplate.convertAndSend(exchanges, routingKey, message,correlation);
    }

1.1.3. 定义Return回调

从交换机到队列的确认

每个RabbitTemplate只能配置一个ReturnCallback,因此需要在项目加载时配置:

@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
    rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
        //发送到队列失败
        @Override
        public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
            log.info("交换机路由到队列失败,message:{} replyCode:{}  replyText:{} exchange:{} routingKey:{}",
                     message, replyCode, replyText, exchange, routingKey);
        }
    });
}

1.2. 消息持久化

生产者确认可以确保消息投递到RabbitMQ的队列中,但是消息发送到RabbitMQ以后,如果突然宕机,也可能导致消息丢失。

要想确保消息在RabbitMQ中安全保存,必须开启消息持久化机制。

  • 交换机持久化
  • 队列持久化
  • 消息持久化

1.2.1. 交换机持久化

RabbitMQ中交换机默认是持久化的。

SpringAMQP中可以通过代码指定交换机持久化:

@Bean
public DirectExchange simpleExchange(){
    // 三个参数:交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
    return new DirectExchange("simple.direct", true, false);
}

默认情况下,由SpringAMQP声明的交换机都是持久化的。

可以在RabbitMQ控制台看到持久化的交换机都会带上D的标示:

服务异步通信-高级篇(RabbitMQ),java,运维

1.2.2. 队列持久化

RabbitMQ中队列默认是持久化的。

SpringAMQP中可以通过代码指定交换机持久化:

@Bean
public Queue simpleQueue(){
    // 使用QueueBuilder构建队列,durable就是持久化的
    return QueueBuilder.durable("simple.queue").build();
}

默认情况下,由SpringAMQP声明的队列都是持久化的。

1.2.3. 消息持久化

利用SpringAMQP发送消息时,可以设置消息的属性(MessageProperties),指定delivery-mode:

  • 1:非持久化
  • 2:持久化

服务异步通信-高级篇(RabbitMQ),java,运维

默认情况下,SpringAMQP发出的任何消息都是持久化的,不用特意指定。

1.3. 消费者消息确认

RabbitMQ是阅后即焚机制,RabbitMQ确认消息被消费者消费后会立刻删除。

RabbitMQ是通过消费者回执来确认消费者是否成功处理消息的:消费者获取消息后,应该向RabbitMQ发送ACK回执,表明自己已经处理消息。

回执分为3种类型:ack、nack、reject。如果消费者返回ack,MQ会把消息从队列删除;如果返回nack或者reject,如果requeue是true的话,MQ会把消息重新投递给消费者,如果requeue是false的话,MQ会把消息删掉。

1.3.1. 场景:

  • 1)RabbitMQ投递消息给消费者
  • 2)消费者获取消息后,返回ACK给RabbitMQ
  • 3)RabbitMQ删除消息
  • 4)消费者宕机,消息尚未处理

这样,消息就丢失了。因此消费者返回ACK的时机非常重要。

SpringAMQP则允许配置三种确认模式:

  • manual:手动ack,需要在业务代码结束后,调用api发送ack。消息投递是不可靠的,可能丢失。自己根据业务情况,判断什么时候该ack。(不推荐)
  • auto:自动ack,由spring监测listener代码是否出现异常,没有异常则返回ack;抛出异常则返回nack,并且requeue是true。类似事务机制,出现异常时返回nack,消息回滚到mq;没有异常,返回ack。
  • none:关闭ack,MQ假定消费者获取消息后会成功处理,因此消息投递后立即被删除(不推荐)

1.3.2. 演示none模式

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: none # 关闭ack

修改consumer服务的SpringRabbitListener类中的方法,模拟一个消息处理异常:

@RabbitListener(queues = "simple.queue")
public void listenSimpleQueue(String msg) {
	log.info("消费者接收到simple.queue的消息:【{}】", msg);
	// 模拟异常
	System.out.println(1 / 0);
	log.debug("消息处理完成!");
}

测试可以发现,当消息处理抛异常时,消息依然被RabbitMQ删除了。

1.3.3. 演示auto模式

把确认机制修改为auto:

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: auto # 关闭ack

在异常位置打断点,再次发送消息,程序卡在断点时,可以发现此时消息状态为unack(未确定状态):

服务异步通信-高级篇(RabbitMQ),java,运维

抛出异常后,因为Spring会自动返回nack,所以消息恢复至Ready状态,并且没有被RabbitMQ删除:

服务异步通信-高级篇(RabbitMQ),java,运维

1.4. 消费失败重试机制

当消费者出现异常后,消息会不断requeue(重入队)到队列,再重新发送给消费者,然后再次异常,再次requeue,无限循环,导致mq的消息处理飙升,带来不必要的压力:

服务异步通信-高级篇(RabbitMQ),java,运维

1.4.1. 本地重试

可以利用Spring的retry机制,在消费者出现异常时利用本地重试,而不是无限制的requeue到mq队列。

修改consumer服务的application.yml文件,添加内容:

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true # 开启消费者失败重试
          initial-interval: 1000 # 初识的失败等待时长为1秒
          multiplier: 3 # 失败的等待时长倍数,下次等待时长 = multiplier * last-interval
          max-attempts: 3 # 最大重试次数
          stateless: true # true无状态;false有状态。如果业务中包含事务,这里改为false
          
 第一次  1秒
 第二次  3*1000 = 3秒
 第三次  3*3000 = 9秒
 第四次  3*9000 = 27秒

重启consumer服务,重复之前的测试。可以发现:

  • 在重试3次后,SpringAMQP会抛出异常AmqpRejectAndDontRequeueException,说明本地重试触发了
  • 查看RabbitMQ控制台,发现消息被删除了,说明最后SpringAMQP返回的是reject,并且不重新入队,mq删除消息了

结论:

  • 开启本地重试时,消息处理过程中抛出异常,不会requeue到队列,而是在消费者本地重试
  • 重试达到最大次数后,Spring会返回reject,消息会被丢弃

1.4.2. 失败策略

在之前的测试中,达到最大重试次数后,消息会被丢弃,这是由Spring内部机制决定的。

在开启重试模式后,重试次数耗尽,如果消息依然失败,则需要有MessageRecovery接口来处理,它包含三种不同的实现:

  • RejectAndDontRequeueRecoverer:重试耗尽后,直接reject,丢弃消息。默认就是这种方式
  • ImmediateRequeueMessageRecoverer:重试耗尽后,返回nack,消息重新入队
  • RepublishMessageRecoverer:重试耗尽后,将失败消息投递到指定的交换机

比较优雅的一种处理方案是RepublishMessageRecoverer

失败后将消息投递到一个指定的,专门存放异常消息的队列,后续由人工集中处理。

@Configuration
public class ErrorMessageConfig {
    @Bean
    public DirectExchange errorMessageExchange(){
        return new DirectExchange("error.direct");
    }
    @Bean
    public Queue errorQueue(){
        return new Queue("error.queue", true);
    }
    @Bean
    public Binding errorBinding(Queue errorQueue, DirectExchange errorMessageExchange){
        return BindingBuilder.bind(errorQueue).to(errorMessageExchange).with("error");
    }
    // 定义一个RepublishMessageRecoverer,关联队列和交换机
    @Bean
    public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
        return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
    }
}

1.5. 总结

如何确保RabbitMQ消息的可靠性?

  • 开启生产者确认机制,确保生产者的消息能到达队列
  • 开启持久化功能,确保消息未消费前在队列中不会丢失
  • 开启消费者确认机制为auto,由spring确认消息处理成功后完成ack
  • 开启消费者失败重试机制,并设置MessageRecoverer,多次重试失败后将消息投递到异常交换机,交由人工处理

2. 死信交换机

2.1. 什么是死信交换机

当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter):

  • 消费者使用basic.reject或 basic.nack声明消费失败,并且消息的requeue参数设置为false
  • 消息是一个过期消息,超时无人消费
  • 要投递的队列消息满了,无法投递

如果这个包含死信的队列配置了dead-letter-exchange属性,指定了一个交换机,那么队列中的死信就会投递到这个交换机中,而这个交换机称为死信交换机(Dead Letter Exchange,检查DLX)。

一个消息被消费者拒绝了,变成了死信。因为simple.queue绑定了死信交换机 dl.direct,因此死信会投递给这个交换机。如果这个死信交换机也绑定了一个队列,则消息最终会进入这个存放死信的队列。

服务异步通信-高级篇(RabbitMQ),java,运维

队列将死信投递给死信交换机时,必须知道两个信息:

  • 死信交换机名称
  • 死信交换机与死信队列绑定的RoutingKey

2.2. TTL

一个队列中的消息如果超时未消费,则会变为死信,超时分为两种情况:

  • 消息所在的队列设置了超时时间
  • 消息本身设置了超时时间

服务异步通信-高级篇(RabbitMQ),java,运维

2.2.1. 接收超时死信的死信交换机

在consumer服务的SpringRabbitListener中,定义一个新的消费者,并且声明 死信交换机、死信队列:

@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "dl.ttl.queue", durable = "true"),
    exchange = @Exchange(name = "dl.ttl.exchange"),
    key = "dl"
))
public void listenDlQueue(String msg){
    log.info("接收到 dl.ttl.queue的延迟消息:{}", msg);
}

2.2.2. 声明一个队列,并且指定TTL

要给队列设置超时时间,需要在声明队列时配置x-message-ttl属性:

@Bean
public Queue ttlQueue(){
    return QueueBuilder.durable("ttl.queue") // 指定队列名称,并持久化
        .ttl(10000) // 设置队列的超时时间,10秒
        .deadLetterExchange("dl.ttl.exchange") // 指定死信交换机
        .deadLetterRoutingKey("dl") // 指定死信交换机绑定key
        .build();
}

这个队列设定了死信交换机为dl.ttl.exchange

声明交换机,将ttl与交换机绑定:

@Bean
public DirectExchange ttlExchange(){
    return new DirectExchange("ttl.direct");
}
@Bean
public Binding ttlBinding(){
    return BindingBuilder.bind(ttlQueue()).to(ttlExchange()).with("ttl");
}

发送消息,但是不要指定TTL:

@Test
public void testTTLQueue() {
    // 创建消息
    String message = "hello, ttl queue";
    // 消息ID,需要封装到CorrelationData中
    CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
    // 发送消息
    rabbitTemplate.convertAndSend("ttl.direct", "ttl", message, correlationData);
    // 记录日志
    log.debug("发送消息成功");
}

发送消息的日志:

服务异步通信-高级篇(RabbitMQ),java,运维

查看下接收消息的日志:

服务异步通信-高级篇(RabbitMQ),java,运维

2.2.3. 发送消息时,设定TTL

@Test
public void testTTLMsg() {
    // 创建消息
    Message message = MessageBuilder
        .withBody("hello, ttl message".getBytes(StandardCharsets.UTF_8))
        .setExpiration("5000")
        .build();
    // 消息ID,需要封装到CorrelationData中
    CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
    // 发送消息
    rabbitTemplate.convertAndSend("ttl.direct", "ttl", message, correlationData);
    log.debug("发送消息成功");
}

服务异步通信-高级篇(RabbitMQ),java,运维

这次,发送与接收的延迟只有5秒。说明当队列、消息都设置了TTL时,任意一个到期就会成为死信。

2.2.4. 总结

消息超时的两种方式是?

  • 给队列设置ttl属性,进入队列后超过ttl时间的消息变为死信
  • 给消息设置ttl属性,队列接收到消息超过ttl时间后变为死信

如何实现发送一个消息20秒后消费者才收到消息?

  • 给消息的目标队列指定死信交换机
  • 将消费者监听的队列绑定到死信交换机
  • 发送消息时给消息设置超时时间为20秒

死信交换机和ttl实现消息延迟发送的缺点?

  • 存在队头阻塞问题

2.3. 延迟交换机

利用TTL结合死信交换机,实现了消费者延迟收到消息的效果。这种消息模式就称为延迟队列(Delay Queue)模式。

但是死信交换机存在队头阻塞问题,因此并不推荐使用。

因为延迟队列的需求非常多,所以RabbitMQ的官方也推出了 DelayExchange 插件,原生支持延迟队列效果。

2.3.1. 安装DelayExchange插件

上传插件

查看数据卷:

docker volume inspect mq-plugins

服务异步通信-高级篇(RabbitMQ),java,运维

将插件上传到这个目录即可

安装插件

进入MQ容器内部来执行安装。我的容器名为mq,所以执行下面命令:

docker exec -it mq bash

进入容器内部后,执行下面命令开启插件:

rabbitmq-plugins enable rabbitmq_delayed_message_exchange

服务异步通信-高级篇(RabbitMQ),java,运维

2.3.2. DelayExchange原理

2.3.2.1. 声明DelayExchange交换机

插件的使用也非常简单:声明一个交换机,交换机的类型可以是任意类型,只需要设定delayed属性为true即可,然后声明队列与其绑定即可。

基于注解方式(推荐):

服务异步通信-高级篇(RabbitMQ),java,运维

也可以基于@Bean的方式:

服务异步通信-高级篇(RabbitMQ),java,运维

2.3.2.2. 发送消息

发送消息时,一定要携带x-delay属性,指定延迟的时间:

服务异步通信-高级篇(RabbitMQ),java,运维

2.3.3. 总结

延迟队列插件的使用步骤包括哪些?

  • 声明一个交换机,添加delayed属性为true
  • 发送消息时,添加x-delay头,值为超时时间

3. 惰性队列

3.1. 消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度,就会导致队列中的消息堆积,直到队列存储消息达到上限。之后发送的消息就会成为死信,可能会被丢弃,这就是消息堆积问题。

服务异步通信-高级篇(RabbitMQ),java,运维

解决消息堆积有两种思路:

  • 增加更多消费者,提高消费速度。也就是我们之前说的work queue模式
  • 扩大队列容积,提高堆积上限

3.2. 惰性队列

从RabbitMQ的3.6.0版本开始,就增加了Lazy Queues的概念,也就是惰性队列。惰性队列的特征如下:

  • 接收到消息后直接存入磁盘而非内存
  • 消费者要消费消息时才会从磁盘中读取并加载到内存
  • 支持数百万条的消息存储

3.2.1. 基于命令行设置lazy-queue

而要设置一个队列为惰性队列,只需要在声明队列时,指定x-queue-mode属性为lazy即可。

可以通过命令行将一个运行中的队列修改为惰性队列:

rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues  

命令解读:

  • rabbitmqctl :RabbitMQ的命令行工具
  • set_policy :添加一个策略
  • Lazy :策略名称,可以自定义
  • "^lazy-queue$" :用正则表达式匹配队列的名字
  • '{"queue-mode":"lazy"}' :设置队列模式为lazy模式
  • --apply-to queues:策略的作用对象,是所有的队列

3.2.2. 基于@Bean声明lazy-queue

服务异步通信-高级篇(RabbitMQ),java,运维

3.2.3. Queue的管理控制台

服务异步通信-高级篇(RabbitMQ),java,运维

ready:已发送到队列,但还未发送给消费者的消息,也就是仅执行了publish的消息。

unacked:已发送给消费者但还未收到消费者ack的信息,即执行了publish和delivery的消息。

total:ready与unacked消息的总和。

in memory:表示在内存中进行缓存的消息数。

persistent:表示在磁盘上存储的持久化的消息数。

transient, paged out:表示非持久化的消息,但实际存储到磁盘上的消息数(可能因为内存达到一定水位触发的置换,也可能是队列为lazy模式,即便是非持久化的消息也存储在磁盘上了)

3.2.4. 总结

消息堆积问题的解决方案?

  • 队列上绑定多个消费者,提高消费速度
  • 使用惰性队列,可以再mq中保存更多消息

惰性队列的优点有哪些?

  • 基于磁盘存储,消息上限高
  • 没有间歇性的page-out,性能比较稳定

惰性队列的缺点有哪些?文章来源地址https://www.toymoban.com/news/detail-786769.html

  • 基于磁盘存储,消息时效性会降低
  • 性能受限于磁盘的IO

到了这里,关于服务异步通信-高级篇(RabbitMQ)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 微服务——服务异步通讯RabbitMQ

     前置文章 消息队列——RabbitMQ基本概念+容器化部署和简单工作模式程序_北岭山脚鼠鼠的博客-CSDN博客 消息队列——rabbitmq的不同工作模式_北岭山脚鼠鼠的博客-CSDN博客 消息队列——spring和springboot整合rabbitmq_北岭山脚鼠鼠的博客-CSDN博客 目录 Work queues 工作队列模式  案例

    2024年02月15日
    浏览(64)
  • 服务异步通讯——RabbitMQ

    微服务间通讯有同步和异步两种方式: 同步通讯 :就像打电话,需要实时响应。 异步通讯 :就像发邮件,不需要马上回复。 两种方式各有优劣,打电话可以立即得到响应,但是一个人却不能跟多个人同时通话。而发送邮件可以同时与多个人收发邮件,但是往往响应会有延

    2024年01月18日
    浏览(44)
  • SpringCloud学习路线(9)——服务异步通讯RabbitMQ

    一、初见MQ (一)什么是MQ? MQ(MessageQueue) ,意思是 消息队列 ,也就是事件驱动架构中的Broker。 (二)同步调用 1、概念: 同步调用是指,某一服务需要多个服务共同参与,但多个服务之间有一定的执行顺序,当每一个服务都需要等待前面一个服务完成才能继续执行。

    2024年02月15日
    浏览(40)
  • 微服务之异步消息通信

    Informal Essay By English I’m sorry that I haven’t updated the article lately because the blogger has been busy with interviews and summarizing their experience. I will create a special article to describe the recent events. Next, let’s get to the topic! 参考书籍: “凤凰架构” “微服务架构设计模式” 引言 以往的文章中我们

    2024年02月05日
    浏览(33)
  • 微服务通信[HTTP|RPC同步通信、MQ异步通信]

    A服务调用B服务,B服务调C服务,C服务调D服务,即微服务之间的通信(也可以叫微服务之间的调用) 一种轻量级的通信协议,常用于在不同的微服务之间进行通信,也是最简单的通信方式 使用REST ful为开发规范,将服务对外暴露的HTTP调用方式为REST API(如GET、POST、PUT、DELETE等),已经成

    2024年02月09日
    浏览(39)
  • 微服务中间件--MQ服务异步通信

    MQ的一些常见问题 消息可靠性问题 消息从发送,到消费者接收,会经历多个过程: 其中的每一步都可能导致消息丢失,常见的丢失原因包括: 发送时丢失: 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机,queue将消息丢失 consumer接收到消息后未消费就宕机

    2024年02月11日
    浏览(48)
  • 微服务RabbitMQ高级篇

    目录 一.消息可靠性传递概述 二.生产者消息确认机制 三.publisher-comfirm 四.publisher-return 五.消息持久化 六.消费者消息确认机制 七.如何确保RabbitMQ消息的可靠性? 八.死信交换机 九.延迟队列 十.惰性队列 十一.MQ集群 生产者发送消息到交换机,交换机将消息路由到队列,消费者

    2024年02月20日
    浏览(38)
  • Java中如何使用消息队列实现异步(ActiveMQ,RabbitMQ,Kafka)

    在 Java 中,可以使用消息队列实现异步处理。下面是一个简单的示例代码,用于说明如何使用 ActiveMQ 实现消息队列异步处理: 添加 ActiveMQ 依赖 在 pom.xml 文件中添加以下依赖: 创建消息队列 创建一个名为 “TestQueue” 的消息队列,并配置 ActiveMQ 连接信息: 创建消息消费者

    2024年02月16日
    浏览(57)
  • 探索 XMLHttpRequest:网页与服务器的异步通信之道(下)

    🤍 前端开发工程师、技术日更博主、已过CET6 🍨 阿珊和她的猫_ CSDN 博客专家、23年度博客之星前端领域TOP1 🕠 牛客 高级专题作者、打造专栏《前端面试必备》 、《2024面试高频手撕题》 🍚 蓝桥云课 签约作者、上架课程《Vue.js 和 Egg.js 开发企业级健康管理项目》、《带你

    2024年02月20日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包