0
点赞
收藏
分享

微信扫一扫

SpringCloud容器化与编排:Docker容器化微服务与Kubernetes部署管理实践

目录

一、介绍

1. 概述

2. 应用场景

3. 工作原理

二、应用

1. 讲述

2. 运用

三、案例

1. 实践 

2. 代码整合

每篇一获


一、介绍

1. 概述

死信交换机是用来处理消息队列中无法被消费者正确处理的消息的交换机。当消息在队列中变成死信时,它会被重新发送到死信交换机,然后被路由到死信队列中进行处理。

死信交换机的作用是将死信消息重新路由到指定的死信队列中,以便进行后续处理。这样可以帮助系统更好地处理无法被消费者正确处理的消息,保证消息队列的稳定运行。

  • 当消息无法路由到队列时,确认消息路由失败。消息成功路由时,当需要发送的队列都发送成功后,进行确认消息,对于持久化队列意味着写入磁盘,对于镜像队列意味着所有镜像接收成功

  • 通过实现 ConfirmCallback 接口,消息发送到 Broker 后触发回调,确认消息是否到达 Broker 服务器,也就是只确认是否正确到达 Exchange 中

2. 应用场景

        1. 错误处理:当消息在队列中无法被正确处理时,可以将其发送到死信交换机,然后再路由到死信队列中进行错误处理和调查。

        2. 重试机制:当消息处理失败时,可以将其发送到死信交换机,并设置重试次数。如果消息在一定次数内仍然无法被处理,可以将其发送到死信队列中,以便进一步处理或记录错误信息。

        3. 延迟消息处理:可以通过设置死信交换机和死信队列来实现延迟消息处理。当消息需要延迟处理时,可以将其发送到死信交换机,并设置一定的延迟时间,然后再路由到指定的死信队列中进行处理。

        4. 日志记录:可以将无法被正确处理的消息发送到死信交换机,并将其路由到死信队列中进行日志记录,以便后续分析和排查问题。

3. 工作原理

        1. 定义死信队列:首先需要在消息队列中定义一个死信队列,用于存放无法被正确处理的消息。

        2. 设置队列属性:在定义普通队列时,可以设置一些属性,如消息的过期时间、消息的最大重试次数等。当消息满足这些属性时,会变成死信消息。

        3. 绑定死信交换机:在定义普通队列时,可以指定该队列的死信交换机和死信路由键。当消息变成死信时,会被发送到死信交换机,并根据指定的路由键路由到死信队列中。

        4. 处理死信消息:一旦消息被发送到死信队列中,就可以进行后续处理,如记录日志、重试处理、延迟处理等。

  • 1.  当消息在普通队列中满足某些条件(如消息过期、消息被拒绝、队列长度超过限制等)时,会变成死信消息。
  • 2.  死信消息会被发送到指定的死信交换机中。
  • 3.  死信交换机会根据指定的路由键将死信消息路由到死信队列中。
  • 4.  死信队列中的消息可以被消费者重新处理,或者进行其他后续处理。

二、应用

1. 讲述

死信,在官网中对应的单词为“Dead Letter”,它是 RabbitMQ 的一种消息机制。

般来说,生产者将消息投递到 broker 或者直接到 queue 里了,consumer 从 queue 取出消息进行消费,如果它一直无法消费某条数据,那么可以把这条消息放入死信队列里面。等待

条件满足了再从死信队列中取出来再次消费,从而避免消息丢失。

  • 消息 TTL 过期
  • 队列满了,无法再次添加数据
  • 消息被拒绝(reject 或 nack),并且 requeue =false

2. 运用

生产者代码: 

消费者代码:

三、案例

  • 消息通过 ACK 确认是否被正确接收,每个 Message 都要被确认(acknowledged),可以手动去 ACK 或自动 ACK

  • 自动确认会在消息发送给消费者后立即确认,但存在丢失消息的可能,如果消费端消费逻辑抛出异常,也就是消费端没有处理成功这条消息,那么就相当于丢失了消息

  • 如果消息已经被处理,但后续代码抛出异常,使用 Spring 进行管理的话消费端业务逻辑会进行回滚,这也同样造成了实际意义的消息丢失

  • 如果手动确认则当消费者调用 ack、nack、reject 几种方法进行确认,手动确认可以在业务失败后进行一些操作,如果消息未被 ACK 则会发送到下一个消费者

  • 如果某个服务忘记 ACK 了,则 RabbitMQ 不会再发送数据给它,因为 RabbitMQ 认为该服务的处理能力有限

  • ACK 机制还可以起到限流作用,比如在接收到某条消息时休眠几秒钟

  • 消息确认模式有:

    • AcknowledgeMode.NONE:自动确认

    • AcknowledgeMode.AUTO:根据情况确认

    • AcknowledgeMode.MANUAL:手动确认

1. 实践 

2. 代码整合

每篇一获

        1. 异常处理和重试机制:通过死信交换机,可以更好地处理消息队列中的异常情况,实现重试机制,提高系统的可靠性和稳定性。

        2. 延迟消息处理:可以利用死信交换机实现延迟消息处理,满足一些特定的业务需求,如定时任务、延迟通知等。

        3. 日志记录和监控:可以将无法被正确处理的消息发送到死信队列中,以便进行日志记录和监控,帮助排查问题和分析系统运行情况。

        4. 架构设计优化:在项目架构设计中考虑死信交换机,可以更好地处理消息队列中的异常情况,提高系统的健壮性和可维护性。

        5. 业务流程优化:对于一些需要延迟处理或重试处理的业务流程,可以利用死信交换机来优化实现,提高系统的灵活性和可扩展性。

举报

相关推荐

0 条评论