Problemas de confiabilidad de mensajes de RabbitMQ, cambios de mensajes fallidos, mensajes retrasados, colas perezosas

confiabilidad del mensaje

Si se trata de una recopilación de registros, si el mensaje se pierde en el proceso MQ (falla en el procesamiento del mensaje, falla en la red, falla en el servidor, etc.), estos mensajes son insignificantes en comparación con la vista general, no tan importantes, y la pérdida se pierde. . Si se tiene en cuenta la fiabilidad del mensaje, el rendimiento se degradará y la pérdida será mayor que la ganancia.
Si es un servicio de pedido, envíe un mensaje a MQ, porque es asíncrono y se notificó al pedido que se realizó con éxito, entonces debe asegurarse de que el mensaje no se perderá. Esto debe garantizar la fiabilidad del mensaje. Aunque se trata de una llamada asíncrona, es necesario asegurarse de que las llamadas asíncronas a cada servicio deben procesarse correctamente.
Cuestiones a tener en cuenta para la fiabilidad del mensaje:

• El mensaje debe ser entregado con éxito al consumidor.
  • El productor es el responsable de la pieza y no habrá problemas.
  • Los consumidores son responsables de que la pieza no salga mal.
  • problema de persistencia de mensajes
• El consumidor debe procesar con éxito el mensaje.

El productor se asegura de que los mensajes se pongan en cola con éxito.

La confiabilidad del mensaje para el productor es responsable de que el mensaje se envíe con éxito a la cola correspondiente. Este proceso se divide en dos partes. La primera parte es si el proceso de envío del mensaje al conmutador es exitoso y si el conmutador se enruta a la cola con éxito. correspondiente a 消息确认y消费回执

mensaje de confirmación

La sección de acuse de recibo del mensaje se divide en tres casos posibles:

1. El productor no pudo enviar el mensaje al intercambio.
2. Si el interruptor está defectuoso, como: no hay un interruptor correspondiente, volveránack
3. Envíe con éxito el mensaje al intercambio especificado, devuelvaack

De forma predeterminada, RabbitMQ no habilita la confirmación de mensajes. Los pasos de configuración son los siguientes:
4. Habilite el mecanismo de confirmación de mensajes en el archivo de configuración.

spring:
  rabbitmq:
    publisher-confirm-type: correlated

5. Mensaje de configuración, especificado como el método de devolución de llamada de error correspondiente

  CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());// 消息的唯一性
        correlationData.getFuture().addCallback(
            result->{
    
    
                if(result.isAck()){
    
    
                // 成功回调
                    System.out.println("消息成功投递到交换机");
                }
                else{
    
    
                // 失败回调 这里可以进行重试
                    System.out.println("消息未成功投递到交换机");
                }
            },
            ex->{
    
    
                System.out.println("发送消息失败");
            }
        );

Al enviar un mensaje, pase correlationData el objeto como parámetro.

rabbitTemplate.convertAndSend("e1","",user,correlationData);

recibo de mensaje

La recepción del mensaje se devuelve cuando se produce un error cuando el conmutador se enruta a la cola.
Los pasos de configuración son los siguientes:

1. en el archivo de configuración

spring:
  rabbitmq:
    publisher-returns: true # 开启消息回执
    template:
      mandatory: true # true 为自定义消息回执回调  false为直接丢弃掉消息

2. Configure la devolución de llamada del recibo del mensaje.
   Un objeto rabbitMQ solo se puede configurar con un recibo de mensaje. Por lo tanto, en la clase, el recibo del mensaje solo se ejecutará cuando el conmutador no se enruta a la cola de mensajes.

@Configuration
public class CommonConfig implements ApplicationContextAware {
    
    
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
    
    
        // 获取RabbitTemplate 
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        // 设置ReturnCallback 
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 投递失败，记录日志
            log.info("消息发送失败，应答码{}，原因{}，交换机{}，路由键{},消息{}",
                     replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有业务需要，可以重发消息
        });
    }
}

Prueba :
el interruptor de prueba falla : envíe un mensaje a un interruptor inexistente, porque el mensaje no se envía al interruptor, por lo que se llamará al método nack en la confirmación del mensaje para probar que

el interruptor no está enrutado a la cola , y el interruptor está vinculado a una cola, luego elimine esta cola a través de la consola de la página

El consumidor se asegura de que los mensajes se eliminen de la cola y se consuman con éxito.

Cuando el productor ha enviado con éxito el mensaje a la cola, la misión del productor está completa. La cola envía la parte restante al consumidor, y luego el consumidor procesa el mensaje
, pero hay dos partes que pueden salir mal:

1. El consumidor falló al recibir un mensaje de la cola
2. El mensajero recuperó con éxito el mensaje de la cola, pero no pudo procesarlo

Mecanismo de Confirmación de Consumo

De cualquier manera, el consumidor no procesó con éxito el mensaje. La idea del juicio es: si el consumidor procesa con éxito el mensaje, devolverá una confirmación. Mientras haya un accidente, la cola no se confirmará, y se considerará que el consumidor no ha procesado con éxito el mensaje final, no se eliminará de la cola.
La confirmación de devolución se divide en tres tipos:

• manual: regrese manualmente, debe llamar a la API en el código
• auto: regresa automáticamente, a través de la función Aop de Spring, el código se mejora y la clase de proxy enviará una confirmación después de que se ejecute el código
• ninguno: obtenga el mensaje y confírmelo de inmediato. Siempre que el consumidor saque el mensaje de la cola, se consumirá correctamente de forma predeterminada y el mensaje en la cola no existirá.这种方式不能保证消息的可靠性

método de modificación

• Modificar en el archivo de configuración

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: 模式

Reflexionando : ¿Cuántos mecanismos de confirmación se envían en el proceso desde que el consumidor saca el mensaje de la cola hasta el consumo exitoso del consumidor? ¿El consumidor envía una confirmación cuando se retira de la cola y luego envía otra confirmación después de que el consumo es exitoso, o solo envía una confirmación después del consumo final exitoso?
Cuando la cola envía un mensaje a la cola, el estado del mensaje se establecerá en unacked, y si el consumidor envía un reconocimiento, el mensaje se eliminará.

Prueba: primero, echemos un vistazo a la situación predeterminada cuando un consumidor saca un mensaje de la cola pero no lo consume.
Después de las pruebas, se encontró que los consumidores no consumían y continuarían haciéndolo 重试. Cuando la parada no puede volver a intentarlo, el mensaje se volverá a poner en cola. (Esta es la

información predeterminada) de la consola, tenga en cuenta que la consola aquí es la versión 3.9, si la versión es demasiado baja, puede ser diferente

El mayor problema con este método es: una vez que falla el consumo, los mensajes en la cola se envían constantemente al consumidor como si patearan una pelota, y el estado cambia constantemente del estado No verificado al estado Listo, lo que consume una gran cantidad de MQ. recursos.Como se muestra en la figura anterior, la barra de envío de mensajes MQ El número se ha disparado a 1700 por segundo.Si
el modo se establece en nono, siempre que el mensaje sea sacado por el consumidor, incluso el 消费失败mensaje del consumidor será descartado por la cola.
También se puede configurar el reintento de mensajes . El valor predeterminado es seguir reintentando mientras falle. constantemente 由队列向消费者发送. Se puede configurar para reintentar localmente de acuerdo con las reglas especificadas.

Mecanismo de reintento de fallo de consumo

El mecanismo de reintento de falla del consumidor es otro mecanismo confiable para el consumo. No utiliza el mecanismo de devolver un acuse de recibo después de la confirmación del consumo, y luego la cola recibe el mensaje de confirmación de eliminación. En cambio, la cola piensa que el consumidor tendrá éxito siempre que envíe un mensaje al consumidor, y luego El mensaje se elimina de la cola (equivalente al modo ninguno), pero el consumidor no puede consumir? Se reintentará localmente. Tenga en cuenta que el reintento se realiza localmente, es decir, la cola solo se envía al consumidor una vez, lo que no afectará el rendimiento de MQ. Después de un procesamiento exitoso, el consumidor devolverá automáticamente un acuse de recibo a la cola. Si falla, lo intentará localmente. Después de que se agote el número de veces, tome las medidas correspondientes de acuerdo con la estrategia de falla correspondiente

Paso de configuración:
cambiar la confirmación del mensaje del consumidor a

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

En este momento, prueba :
cuando el consumidor saca el mensaje, MQ marca el mensaje como un mensaje Unacked. Cuando el procesamiento del mensaje falla, lo volverá a intentar localmente. Cuando el número de reintentos exceda el límite superior configurado, MQ seguirá descartando el mensaje. .
Puede interrumpir el punto para juzgar cuántas veces ha reintentado al final. Cuando el consumo falla, si no se excede el límite superior de falla, el método de devolución de llamada se volverá a llamar automáticamente. Cuando el número de reintentos exceda el límite

superior , uno se enviará automáticamente rejecty la cola terminará删除掉消息

Entonces esto trae un problema: si los múltiples intentos locales aún fallan, y la confiabilidad del mensaje aún no está garantizada,
entonces la estrategia de falla debe modificarse. El valor predeterminado es regresar cuando el número de fallas alcanza el límite superior reject, por lo que que el mensaje se elimine en la cola

estrategia de fracaso

Hay varios tipos de estrategias de falla.

• RejectAndDontRequeueRecoverer: directo después de que se agoten los reintentos reject，丢弃消息. Cuando se selecciona el reintento local, la falla alcanza el límite superior, que es el valor predeterminado, como se demostró anteriormente

• ImmediateRequeueMessageRecoverer: después de que se agoten los reintentos, regrese nack，消息重新入队y patee la pelota nuevamente

• RepublishMessageRecoverer: después de que se agoten los reintentos, entregue el mensaje de falla al intercambio especificado

Este es el último método de procesamiento: cuando el consumidor no puede procesar el mensaje y alcanza el límite superior, actuará como productor y enviará mensajes a otros conmutadores.

Use el tercer método: el consumidor especifica el conmutador que se reenvía después de la falla

Este método es como si yo fuera la Parte B, pero no puedo manejarlo, así que yo, como Parte A, busco otra Parte B para manejar la prueba
: cuando el productor envía un mensaje al conmutador, el conmutador lo enruta a la cola. , y el consumidor toma el mensaje de la cola, inicia el procesamiento local, falla y vuelve a procesar. Cuando la falla de procesamiento alcance el límite superior, se reenviará al conmutador de procesamiento de fallas configurado.

1. El productor envía un mensaje al intercambio.
   
2. El consumidor sacó el mensaje de la cola, no pudo procesarlo varias veces, pero no alcanzó el límite superior y siguió intentándolo.
   
   
3. Cuando el número de fallas de procesamiento del consumidor alcance el límite superior,
   
   verifiquemos el mensaje reenviado por el consumidor en la cola de errores.Podemos ver que no solo el contenido del mensaje original, sino que también el consumidor agregó información de error al mensaje.
   

Use un servicio para escuchar esta cola de errores, de modo que los mensajes de fallas de otros servicios puedan procesarse nuevamente de manera uniforme

Use el primer método: especifique un interruptor de mensaje fallido en la cola

Dado que el uso del interruptor de letra muerta no se limita a este escenario, en aras de una estructura clara, aquí solo se proporciona una introducción general. El seguimiento presentará en detalle
que el interruptor de mensajes fallidos está configurado en la cola de mensajes. Cuando el consumidor no puede procesar los mensajes localmente y alcanza el límite superior, se adopta la primera estrategia de falla para devolver el rechazo. La cola de mensajes original es la igual que ack después de recibir esta confirmación: enviar directamente El mensaje se descarta, pero después de configurar el conmutador de mensajes fallidos, se reenviará al conmutador de mensajes fallidos, y el conmutador de mensajes fallidos se enrutará a la cola de mensajes fallidos, y luego también hay un consumidor dedicado a procesar mensajes fallidos.

Este método es como si yo fuera la Parte B, pero no puedo manejarlo, le diré a la Parte A directamente y la Parte A encontrará a otra persona para que sea la Parte B.

problema de persistencia de mensajes

A través del mecanismo de confirmación de consumo del productor anterior, se ha realizado el mecanismo de confirmación del consumidor, y el consumidor debe procesar con éxito el mensaje reenviado por el productor. Pero si en medio del proceso del mensaje, MQ falla, el mensaje ha llegado a la cola y se ha confirmado al productor, pero el consumidor no sabe que hay un mensaje para él. En este momento, el tiempo de inactividad es no es persistente y se pierde todo el mensaje.
Para garantizar que después de que todo el enlace esté inactivo, aún se pueda restaurar al estado anterior al tiempo de inactividad, se deben considerar tres problemas de persistencia

• cambiar la persistencia
• persistencia de la cola
• Tenga en cuenta que el valor de la persistencia del mensaje
  es: utilice Spring AMQP para declarar o crear 交换机y 队列envíe 消息el valor predeterminado 都是持久化.
  Prueba :
  cuando estaba probando el interruptor incorrecto, el interruptor declarado, la cola y los mensajes en la cola todavía estaban allí. En este momento, usé la ventana acoplable para reiniciar RabbitMQ para juzgar si todavía estaba allí.
  

Por supuesto, cuando usa springAMQP, también puede declarar explícitamente la persistencia (también un método para configurar la no persistencia)

cambiar la persistencia

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

persistencia de la cola

@Bean
   public Queue errorQueue(){
    
    
       return new Queue("error.queue",true);
   }

persistencia del mensaje

Entonces, ¿qué operaciones tendremos cuando solo ingresamos una cadena?

Resumen :

como se mencionó anteriormente, los reintentos locales se utilizan después de que falla el procesamiento del mensaje del consumidor. Cuando el número de reintentos supera el número especificado, el consumidor puede reenviar el mensaje sin procesar a un conmutador determinado o enviar un rechazo a la cola para permitir que el mensaje Se convierte en mensaje fallido y es manejado por el intercambio de mensajes fallidos especificado por la cola. Aquí se explica cómo usar el interruptor de mensajes fallidos para la cola

intercambio de letra muerta

Intercambio de mensajes fallidos, como su nombre lo indica, es enviar los mensajes fallidos en cada cola a este 交换机, Intercambio de mensajes fallidos es la abreviatura DLK
de Entonces, ¿qué es un mensaje fallido? Hay tres tipos de letras muertas

1. 未被成功消费的消息: El consumidor adopta el mecanismo de reintento local y la estrategia de falla es el envío final rejectEn este momento, el mensaje en la cola no se consume con éxito y se convierte en letra muerta
2. 超时的消息: Puede ser que la cola haya establecido ttl y el tiempo de espera de la cola también puede ser que el mensaje haya establecido ttl y el mensaje haya expirado. Cuando se agota el tiempo de espera de la cola, todos los mensajes de la cola se convierten en mensajes fallidos, y cuando se agota el tiempo de espera del mensaje, solo este mensaje es un mensaje fallido.
3. 队列溢出的消息: Debido a que el espacio de la cola es limitado, cuando los mensajes se colocan en la cola durante mucho tiempo hasta que la cola no tiene espacio para almacenar temporalmente estos mensajes, algunos de los primeros mensajes se liberarán y se convertirán en mensajes fallidos, y luego se enviarán mensajes nuevos. almacenado

¿Cómo hacer que un intercambio sea un intercambio de letra muerta?
Un conmutador de mensajes fallidos es un conmutador ordinario. Para un conmutador de mensajes fallidos 生产者是队列, la cola que se le envía especifica su conmutador de mensajes fallidos, y luego los mensajes fallidos en la cola se enviarán automáticamente al conmutador de mensajes fallidos.

---

No se pudo configurar un interruptor de mensajes fallidos

planificación

tipo	nombre
intercambio de letra muerta	dl.e2
cola de mensajes fallidos	dl.q2
interruptor común	e2
cola normal	q2

Configuración: cuando falla el procesamiento del consumidor de la cola q2, se entrega al consumidor de la cola de mensajes fallidos dlq2

1. La configuración de una cola de mensajes fallidos es un conjunto común de conmutadores, colas y relaciones vinculantes. Y especifique el consumidor para la cola.

  @Bean
    public DirectExchange dle2(){
    
    
        return new DirectExchange("dle2");
    }
    @Bean
    public Queue dlq2(){
    
    
        return new Queue("dlq2");
    }
    @Bean
    public Binding dlbinding(){
    
    
        return BindingBuilder.bind(dlq2()).to(dle2()).with("a1");
    }

 @RabbitListener(queues = "dlq2")

 public void listenDirectQueue2(String msg) {
    
    

  System.out.println("死信队列中"+msg);
 }

2. Configure conmutadores y colas normales y vincúlelos. La cola debe especificar el intercambio de mensajes fallidos y luego especificar sus consumidores

@Bean
    public Queue q2(){
    
    
        return QueueBuilder.durable("q2")
                .deadLetterExchange("dle2")
                .build();
    }

    @Bean
    public DirectExchange e2(){
    
    
        return new DirectExchange("e2");
    }
    @Bean
    public Binding binding(){
    
    
        return BindingBuilder.bind(q2()).to(e2()).with("a1");
    }

Especifique el consumidor, el consumidor requiere configurar el mecanismo de reintento local y el consumidor manejará la falla

3. El productor envía un mensaje al intercambio, que desconoce al productor.
   

Resultado de la prueba:
la cola q2 falló dos veces y luego la cola dlq2 recibió el mensaje

---

Configuración de un interruptor de letra muerta TTL

Establezca el período de validez del mensaje en la cola, pero no hay consumidor para el mensaje en esta cola, es decir, el mensaje enviado a esta cola, por no poder consumirse, se convertirá en letra muerta si supera el período de validez de la cola, y luego establezca un interruptor de mensajes fallidos para la cola. Luego vincule una cola para el interruptor de mensajes fallidos, y un consumidor monitorea la cola, para que los mensajes se puedan enviar al consumidor después del tiempo.
Por lo tanto, la cola de mensajes fallidos TTL se puede usar para enviar mensajes a intervalos regulares (la cola con un período de validez no tiene consumidores y el mensaje debe convertirse en un mensaje fallido) y el procesamiento de mensajes de tiempo de espera (entrega de mensajes no procesados ​​a otros consumidores) .
Por supuesto, no solo se puede configurar el período de validez para la cola, sino que también se puede configurar el período de validez para el mensaje. El período de validez de la cola es equivalente a establecer el período de validez para todos los mensajes en la cola, y el período de validez del mensaje se refiere a un solo mensaje. Si se agota el tiempo, se utilizará como letra muerta de esta cola.

Configure todos los mensajes en la cola para retrasar el mensaje Pasos: Si la función del consumidor se especifica para la cola del período de validez, se convierte en: el mensaje de tiempo de espera es procesado por otros conmutadores
Planificación

tipo	nombre
intercambio de letra muerta	dl.e1
cola de mensajes fallidos	dl.q1
interruptor común	e1
cola normal	q1

1. Primero cree un interruptor de mensajes fallidos, luego vincule la cola y habrá consumidores escuchando en el otro extremo de la cola (el interruptor de mensajes fallidos es el mismo que el normal)

2. Cree un conmutador y una cola de temporización, y especifique su conmutador de mensaje muerto como el valor del conmutador configurado previamente. Tenga en
   
   cuenta que: la cola de retraso no puede tener consumidores, porque si hay consumidores, el mensaje no se bloqueará en la cola y no no supere el periodo de validez, se consumirá cuando quede en letra muerta

3. El productor envía un mensaje al conmutador, y el conmutador establecerá
   
   un retraso de mensaje único para la cola del período de validez . Aquí, en lugar de especificar TTL para la cola, se especifica TTL para el mensaje en el lado del productor. En cuanto a la letra muerta cola, es lo mismo que arriba

Por ejemplo: coloque el mensaje en el objeto Mensaje, especifique en el objetoTTL

Message message = MessageBuilder
        .withBody("hello, ttl message".getBytes(StandardCharsets.UTF_8))
        .setExpiration("5000")
        .build();

Pensando: 共有几种方式设置消息有效期？
hay dos tipos, uno es para especificar el período de validez para todos los mensajes en la cola, y el otro es para especificar el período de validez para un solo mensaje. Ponga la información del
如何实现订单15分钟有效？
pedido en una cola de retraso, que establece el período de validez en 15 minutos, pero no establece el pedido del consumidor. La información se bloquea en esta cola durante 15 minutos y luego se entrega al interruptor de mensajes fallidos, y los consumidores de la cola de mensajes fallidos correspondientes al switch de mensajes fallidos cancelan el ordenar de acuerdo a la información después de recibir el mensaje.

---

Por supuesto, para lograr el envío retrasado de mensajes, no solo puede usar el método de establecer el período de validez de la cola y luego consumirlo a través de la cola de mensajes fallidos, sino que RabbitMQ también proporciona un complemento dedicado 延迟消息. En cuanto al hecho de que la cola de mensajes está llena, cuando se inserta un mensaje nuevo, el mensaje más antiguo de la cola se convierte en letra muerta, lo que no se demostrará aquí. A continuación, presentaremos la implementación de mensajes retrasados ​​mediante el uso de complementos.

mensaje retrasado

Escenarios de aplicación de mensajes retrasados : los mensajes retrasados ​​se pueden usar para establecer el período de validez, el tiempo, la cita, etc.
El funcionario proporciona un DelayExchangecomplemento para implementar mensajes retrasados, que se implementa en función de los cambios en lugar de las colas. Aunque los intercambios no pueden almacenar mensajes, se utilizan complementos

Instalación del complemento DelayExchange

1. Primero, descargue el complemento primero. Tenga en cuenta que la versión del complemento debe ser coherente con la versión de MQ. La dirección de descarga es https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases
   
2. A continuación, coloque el complemento en el directorio de complementos de MQ.
   Aquí se inicia RabbitMQ con Dokcer, y el directorio de complementos se montó fuera al inicio.
   Comandos cuando se inicia RabbitMQ

docker run \
 -e RABBITMQ_DEFAULT_USER=yan\
 -e RABBITMQ_DEFAULT_PASS=1234 \
 -v mq-plugins:/plugins \
 --name mq \
 --hostname mq \
 -p 15672:15672 \
 -p 5672:5672 \
 -d \
 3.9.27-management-alpine

En el comando, el directorio del complemento MQ se monta en el mq-pluginsvolumen lógico indicado. Use el comando docker volume inspect mq-pluginspara ver el directorio del host correspondiente al volumen lógico.

Coloque .ezel complemento final en este directorio

. ¿Por qué nuestro complemento parece estar fuera de lugar? de lugar, porque necesita ser instalado

3. Instalar el complemento La
   instalación del complemento debe ingresar al contenedor para la instalación, usar el comando docker exec -it mq bashy luego usar el comando rabbitmq-plugins enable rabbitmq_delayed_message_exchangepara completar la instalación

Después de completar la instalación
, ¿cómo se usa el interruptor de retardo? La generalización es especificar el conmutador para delayed类型establecer el tiempo de retraso del mensaje.
El conmutador de retraso se declara como un tipo sobre la base del conmutador ordinario. delayedLuego, al enviar un mensaje, si el mensaje se envía a este conmutador, debe se agregará al principio del mensaje Atributo x-delay, el valor es el tiempo que desea retrasar. Al enviar un mensaje, el interruptor de retraso conocerá x-delayel tiempo de retraso de acuerdo con el valor del atributo del encabezado del mensaje, conservará el mensaje en el disco y lo volverá a publicar en la cola vinculada a él cuando llegue el momento.
Es decir, aunque el interruptor se declara como un interruptor 延迟交换机, es una mejora sobre la base de un interruptor normal y aún tiene las funciones de un interruptor normal.
Usemos el código para demostrar este proceso:
Declare el interruptor como un interruptor de retardo , usando el mismo método de @Bean y anotación

• Usar anotaciones
  
• La forma de usar @Bean
  

Cuando el productor envía un mensaje, necesita agregar un atributo al encabezado de solicitud del mensaje x-delay. El valor es la cantidad de milisegundos de retraso.

Durante la prueba, se descubrió que cuando el mensaje se enviaba al interruptor de retraso, porque el conmutador no enrutó el mensaje a la cola a tiempo, se activaría la confiabilidad del mensaje.El método de recepción del mensaje se puede juzgar de acuerdo con la información devuelta, y esta situación se ignora

---

El uso del complemento de mensajes retrasados ​​puede reemplazar el uso de la cola de mensajes fallidos. Hay otro punto sobre el problema de los mensajes fallidos: el mensaje más antiguo en la cola se convierte en mensaje fallido debido a la falta de espacio en la cola. Puede usar el conmutador para recibir mensajes fallidos. la letra muerta para su tramitación, pero ¿cómo evitarlo?, ¿y esta situación?

1. Aumentar el poder de procesamiento del consumidor
2. Mejorar la capacidad de la cola
   Mejorar la capacidad de procesamiento de los consumidores no está dentro del alcance de MQ Aquí discutimos el segundo método para mejorar la cola de mensajes.

Colas perezosas Quenes perezosas

¿Qué es una cola perezosa? Una comprensión simple es almacenar el mensaje directamente en el disco y luego leerlo desde el disco cuando se usa.
¿Por qué se llama cola perezosa? Entonces, el disco es más lento que la memoria, ¿
por qué usar la cola perezosa? La cola perezosa existe en el disco. Aunque el disco es lento, tiene un gran espacio, lo que resuelve efectivamente el problema de la acumulación de mensajes. Y la velocidad es estable.Cuando no se usa la cola inerte, los mensajes en la memoria se transferirán al disco después de alcanzar una cierta cantidad.Sin embargo, la concurrencia de MQ en este proceso IO disminuirá, mostrando un fenómeno de fluctuación. En su lugar, se utiliza una cola inerte y los mensajes se colocan directamente en el disco, sin intermitencia page-out, y la velocidad es relativamente estable.
¿Cuáles son las desventajas de las colas perezosas? La desventaja de la cola perezosa es la desventaja de almacenar datos en el disco: tanto el almacenamiento como la recuperación deben pasar por el disco, ¡y la puntualidad es deficiente! ¡Disk IO será peor que el rendimiento de la memoria!

El uso de colas perezosas
Las colas perezosas son un tipo de colas que se MQ3.6lanzaron después de la versión.
El uso de colas diferidas también se usa al declarar colas, y también hay dos formas de @Bean y anotaciones.Tenga en cuenta que los mensajes retrasados ​​son para configurar conmutadores y las colas diferidas son para configurar colas.

• @bean camino
  
• La forma de
  
  enviar mensajes de anotación no ha cambiado, solo modifique las propiedades de la cola para que los mensajes se almacenen directamente en el disco y luego se recuperen del disco cuando sea necesario. Además, también puede usar comandos para modificar las colas existentes
  para colas perezosas
  Por ejemplo: quiero modificar una cola común llamada q4 en una cola perezosa
  
  dentro del contenedor MQ usando el comandorabbitmqctl set_policy Lazy "^q4$" '{"queue-mode":"lazy"}' --apply-to queues