【面试 MQ可靠生产和消费，定向，延迟消费，避免重复消费】冗余表+回执。手动ack+死信队列。公网和内网通信和防止坏人。TTL和死信Exchange。延时插件实现延时交换机

天海华兮

已于 2023-04-06 16:35:03 修改

阅读量397

点赞数 1

分类专栏：消息队列文章标签： rabbitmq 可靠性生产可靠性消费延迟消费定向消费

于 2023-04-06 15:16:53 首次发布

原文链接：https://www.jianshu.com/p/caba8c9e70fd

版权

消息队列专栏收录该内容

9 篇文章 0 订阅

订阅专栏

1. 可靠性生产：冗余表+回执

1:为了保证数据一定发送到MQ中
2:在同一事务中，增加一个冗余表的记录订单数据每条教据和是否是发送成功的状态
3:然后利用RabbitMQ提供的publisher/Confirm机制开启确认机制后，如果消息正常发送到MQ中就会获取到回执信息。然后把状态修改为已发送状态啊

如果没有回执，使用定时器
- 消息为未发送的消息，重新发送到Mq

@EnableScheduling
public class TaskService {
    @Scheduled(cron = "秒 分 时 日 月 年 周")
    public void sendMessage() {
        //消息为0的状态的消息，重新发送到Mq
    }
}

spring:
  rabbitmq:
    publisher-confirm-type: correlated #有相互关系的。投递消息的 确认机制，一定要配置

correlate
英
/ˈkɒrələt/
v.
相互关联；显示紧密联系
n.
相关的事物

Correlation
n.
相互关系，关联；相关量

setConfirmCallback

	@PostConstruct //其实是java自己的注解
    public void regCallback() {
        //其实就是给 rabbitTemplate 扩展了方法。
        //消息发送成功以后，给子生产者的消息回执，来确保生产者的可靠性
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                System.out.println("cause" + cause);

                String orderId = correlationData.getId();
                System.out.println("数据的ID" + orderId);

                //如果没有ack成功
                if (!ack) {
                    //应答失败，也可以存到 其他地方
                    System.out.println("mq应答失败");
                    return;
                }

                System.out.println("应答成功了");
                //应答成功，更新数据库，状态改为1 （已发送到Mq）
            }
        });
    }

		//发送时 如此设置
        rabbitTemplate.convertAndSend("direct_order_exchange"
                , "sms", "order的json数据" + content,
                new CorrelationData(content));

2. 可靠性消费：手动ack+死信队列

解决消息重试的集中方案:

控制重发的次数 + 死信队列
- 如果不加死信队列，重试次数到了，会扔了。
try+catch+手动ack
try+catch+手动ack +死信队列处理+人工干预

1:利用RabbitMQ的ACK机制，由消费者自身控制清息的重发、清除。和丢弃

2:考虑问题:幂等性问题，因为定时里发会造成消息的重发发送。可以使用唯—主键，或者redis的分布式锁

手动ACK 配置

acknowledge-mode: none 自动模式（默认开启）

acknowledge-mode: manual  手动模式

acknowledge-mode: auto 自动模式 （根据侦听器检测是正常返回、还是抛出异常来发出 ack/nack）

手动模式可以确保我们在没有签收的情况下保证消息的不丢失。
即使服务器宕机的情况下，只要没有手动ack,都是unacked状态,这时候会将这条消息重新放回队列，变成ready状态。

spring:
  rabbitmq:
    host: 服务器地址
    port: 5672
    username: admin
    password: 123
    listener:
      direct: #直连的
        acknowledge-mode: manual # 开启手动确认
    publisher-confirm-type: correlated # 开启异步确认机制。投递消息的 确认机制。可靠性生产用
    
spring:
  rabbitmq:
    listener:
      simple: #简单模式
        acknowledge-mode: manual

        ack now ledge - mode: manual #手动ack

manual
英
/ˈmænjuəl
adj.
手工的，体力的；手动的，用手操作的
n.
使用手册，说明书；手动换挡的车辆；风琴键盘；（牧师主持圣礼时用）礼仪书

ledge
英
/ledʒ/
n.
岩架；壁架；窗台；暗礁；矿层

knowledge
英
/ˈnɒlɪdʒ/
n.
知识，学问；知道，了解；计算机系统存储的信息；（与见解相对的）认知

手动ACK 接收

    //@RabbitHandler
    @RabbitListener(queues = {"sms.direct.queue"}) //直接这样写，也可以
    public void receiveMessage(String message, Channel channel,
                               @Header(AmqpHeaders.DELIVERY_TAG) long tag) throws IOException {
        System.out.println("email direct模式收到了消息" + message + "===" + count++);
        try {
            int i = 1 / 0;
            System.out.println(i);
            //手动ack已经正常消费
            channel.basicAck(tag, false);
            
        } catch (Exception e) {
            //如果出现异常的情况下，根据实际的情况去进行重发
            //重发一次后.丢失．还是日记．存库根据自己的业务场景去决定
            
            //参数1:消息的tag参数 2: false多条处理参数 3: requeue重发
            
            // false不会重发,会把消息打入到死信队列
            // true 的会会死循环的重发，建议如果使用true的话，不加try/catch否则就会造成死循环
            channel.basicNack(tag, false, false);//单条 不重发。直接扔掉（进入死信队列）
        }
    }

绑定死信队列

@Configuration
public class DeadRabbitConfig {

    //创建一个 死信队列
    @Bean
    public Queue deadQueue() {
        Map<String, Object> args = new HashMap<>();
        return new Queue("dead.direct.queue", true, false, false, null);
    }

    //创建一个 死信交换器
    @Bean
    public DirectExchange deadDirectExchange() {
        return new DirectExchange("dead_direct_exchange", true, false);
    }

    //死信队列 绑定到 交换器
    @Bean
    public Binding deadBinding() {
        return BindingBuilder.bind(deadQueue()).to(deadDirectExchange()).with("dead");
    }
}


	//创建 短信消息队列
    @Bean
    public Queue smsQueue() {
        Map<String, Object> args = new HashMap<>();
		//死信 交换器 指定。指定的就是上面创建的 交换器
        args.put("x-dead-letter-exchange", "dead_direct_exchange");
        //死信 routing-key 路由键
        args.put("x-dead-letter-routing-key", "dead");
        return new Queue("sms.direct.queue", true, false, false, args);
    }

3. 公网和内网通信

内网中，有个单独的项目，连接的是公网的MQ，
- 这个项目收到公网发送的MQ消息，就 feign 到内网的其他项目。

4. 防坏人起消费者

公网的MQ，怎么避免他人连接（用户名密码他人知道的话）
- 白名单
  - 设置防火墙设置端口访问，设置白名单
  - 配置白名单的三种方式：
    - Mq和spring集成的时候，做Ip白名单限制
    - 在mq send 的时候带上特定的Ip
    - 需要在rabbit mq 后台管理系统上面配置用户
- 消息为加密的，秘钥为动态的：des 对称加密算法 + rsa非对称加密
  - 秘钥需要用当前的IP + 登录信息去拿。
  - 发现账号相同， IP 不同，抢占秘钥，立刻警报

定向消费

https://jiuaidu.com/jianzhan/781808/

rabbit Mq 实现定向消费，设置Ip白名单：

本地启动生产环境。就会有可能消费生产环境的消息。

方案一：Mq和spring集成的时候，做Ip白名单限制。在启动项目的时候就会检测本地的Ip是否属于配置的白名单Ip段（缺点：就是只能围绕）

# remote Mq Ip List(Ip 白名单)
consumers.Ip=222.222.222.0/24

方案二：在mq send 的时候带上特定的Ip. 然后在消费端进行判断，如果消费端不属于Ip白名单，那么直接再次放进mq，或者说抛异常。（缺点：直接放回mq，做法不好，每次放入顶端，抛异常感觉不错，但是得把Mq配置成支持事务的方式））

方案三：需要在rabbit mq 后台管理系统上面配置用户，且需要rabbit.confg 里面配置固定的白名单Ip

5. 如何避免消息重复消费：发送时设唯一

消费者端实现幂等性，意味着消息永远不会消费多次，即使收到了多条一样的消息。通常有两种方式来避免消费重复消费：

方式1: 消息全局 ID 或者写个唯一标识(如时间戳、UUID 等) ：每次消费消息之前根据消息 id 去判断该消息是否已消费过，如果已经消费过，则不处理这条消息，否则正常消费消息，并且进行入库操作。(消息全局 ID 作为数据库表的主键，防止重复)

基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据

方式2: 利用 Redis 的 setnx 命令：给消息分配一个全局 ID，消费该消息时，先去 Redis 中查询有没消费记录，无则以键值对形式写入 Redis ，有则不消费该消息。

6. 延迟消费

订单下单之后30分钟后，如果用户没有付钱，则系统自动取消订单。
车到入口后，X分钟，没人过来，设置成超时。

消息的TTL和死信Exchange

https://www.cnblogs.com/haoxinyue/p/6613706.html

Time To Live 消息的存活时间
- 如果队列设置了（存活时间），消息也设置了，那么会取小的
可以通过设置消息的expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果。
- 只是expiration字段是字符串参数，所以要写个int类型的字符串：

byte[] messageBodyBytes = "Hello, world!".getBytes();

AMQP.BasicProperties properties = new AMQP.BasicProperties();

properties.setExpiration("60000");

channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);

进入死信路由的情况：拒收过期满载

一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。
上面的消息的TTL到了，消息过期了。
队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。

Dead Letter Exchanges 死信交换机

记住这里是路由而不是队列，一个路由可以对应很多队列。

Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。

只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

具体实现

方法就是TTL+死信队列,组合实现延迟队列的效果

延迟任务通过消息的TTL和Dead Letter Exchange来实现。我们需要建立2个队列，一个用于发送消息，一个用于消息过期后的转发目标队列。

生产者输出消息到Queue1，并且这个消息是设置有有效时间的，比如60s。消息会在Queue1中等待60s，如果没有消费者收掉的话，它就是被转发到Queue2，Queue2有消费者，收到，处理延迟任务。

Consumer第一个收到的还是10。虽然10是第一个放进队列，但是它的过期时间最长。所以由此可见，即使一个消息比在同一队列中的其他消息提前过期，提前过期的也不会优先进入死信队列，它们还是按照入库的顺序让消费者消费。

如果第一进去的消息过期时间是1小时，那么死信队列的消费者也许等1小时才能收到第一个消息。
只有当过期的消息到了队列的顶端（队首），才会被真正的丢弃或者进入死信队列。

所以在考虑使用RabbitMQ来实现延迟任务队列的时候，需要确保业务上每个任务的延迟时间是一致的。如果遇到不同的任务类型需要不同的延时的话，需要为每一种不同延迟时间的消息建立单独的消息队列。

使用延时插件实现【延时交换机】

https://www.jianshu.com/p/caba8c9e70fd

使用延时交换机实现延时消息更加灵活，可以针对每个消息设置任意的过期时间，交换机中的消息如果过期将路由到绑定的队列中进行消费；

spring:
  cloud:
    stream:
      bindings:
        input:
          destination: delay_message_exchange #输入输出的交换器
          group: test-service
        output:
          destination: delay_message_exchange
      rabbit:
        bindings:
          input: #输入
            consumer: #消费者
              delayed-exchange: true #延迟交换器为 true
          output:
            producer:
              delayed-exchange: true

定义两个队列并声明为延时exchnage，delayed-exchange需rabbitmq延时插件支持，在发送消息时带上x-delay参数指定过期时间；

    public void sendDelayExchangeMessage(String message) {
        
        log.info("send message {}", message);
        
        processor.output().send(MessageBuilder.withPayload(message)
                                .setHeader("x-delay",20000).build());
    }

使用队列的方式只能用于所有消息的过期时间均相同的情况下，延时中的消息总数可以延时队列中查看到，使用交换机插件的方式更加灵活，可以针对每个消息设置不同的超时，适应更多的业务场景，延时中的消息总数可以延时的交换机中查看到；

延迟队列生产者使用 x-delay 设置延迟时长，单位 ms。经测试，此 delayTime 设置过长（未超过 long 限制）时，延迟队列失效，会立刻被消费掉。

此处应该是该插件有问题，多次尝试后，发现一个有趣的现象，设置 delayTime = 2147483648l 2 时出现此问题，delayTime = 2147483648l 2 - 1 时正常，说明该插件使用了 4 个字节用来表示延时时常，delayTime设置过大溢出后，变为负数，导致该消息立即被执行。因而该插件最多只能支持延迟 49 天左右。
费了这么半天的劲，竟然没有去读它的文档。

rabbitmq-delayed-message-exchange文档Performance Impact一节已明确说明了这个限制。

https://zhuanlan.zhihu.com/p/467725873

安装延迟插件

https://blog.csdn.net/u010833154/article/details/124947324

插件rabbitmq_delayed_message_exchange实现延迟队列;

https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
这里下载rabbitmq对应的文件即可，

把下载的文件rabbitmq_delayed_message_exchange-20171215-3.6.x.ez放倒rabbitmq的plugins下
然后执行

#启用rabbitmq_delayed_message_exchange
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

然后可以查看rabbitmq_delayed_message_exchange是否被启用

rabbitmq-plugins list

[e*] amqp_client                       3.6.5
[e*] mochiweb                          2.13.1
[  ] rabbitmq_amqp1_0                  3.6.5
[E*] rabbitmq_delayed_message_exchange 20171215-3.6.x

[E*]和[e*]表示启用
然后重启rabbitmq即可

service rabbitmq-server restart
或者
rabbitmq-server restart

然后打开mq管理界面就可以看到x-delayed-message，即表示延迟队列安装成功，使用延迟队列记得参数加上x-delayed-type

配置交换机、队列、路由键
- x-delayed-type

@Bean
public CustomExchange delayedExchange() {
	Map<String, Object> args = new HashMap<>();
    args.put("x-delayed-type", "direct");
    
    CustomExchange customExchange = new CustomExchange(YOUR_EXCHANGE_NAME, "x-delayed-message", true, false, args);
    return customExchange;
}

@Bean
public Queue delayedQueue() {
	return new Queue(YOUR_QUEUE_NAME);
}

@Bean
public Binding delayedBinding() {
    //队列绑定交换器
	return BindingBuilder.bind(delayedQueue())
        .to(delayedExchange())
        .with(YOUR_ROUTING_KEY).noargs();
}

public void sendDelayed(String message, Long millis) {
	rabbitTemplate.convertAndSend(YOUR_EXCHANGE_NAME, YOUR_ROUTING_KEY, message, msg -> {
    	msg.getMessageProperties().setHeader("x-delay", millis);
        	return msg;
    });
}