Hace poco leí @JavaGuide publicó un artículo , "el entrevistador me preguntó cómo asegurarse de que el mensaje no se pierde Kafka? Lloré! " Este artículo para llevar a cabo este tema para hablar de cómo garantizar que los mensajes no RocketMQ perdidos.
0x00. Proceso de transmisión de mensajes
Un mensaje es desde la producción hasta el consumo, vamos a ir a través de tres etapas:
- etapa de producción, Productor nuevo mensaje, entonces el mensaje que envía la red a la MQ Broker
- etapa de almacenamiento, el mensaje se almacena en el disco final Broker
- fase mensaje, al Consumidor se tire mensaje del Broker
Cualquiera de estas etapas puede haber pérdida de mensajes, siempre y cuando nos encontramos con estas tres etapas razones perdieron mensajes, usando manera razonable para evitar la pérdida, puede resolver el problema de la pérdida de mensajes.
0x01. Etapa de producción
Productores (Productor) agente envía un mensaje a la red, cuando el agente recibió devolverá un mensaje de respuesta de acuse de recibo al Productor. En tanto que el productor recibe el mensaje de respuesta de acuse de recibo devuelto en nombre no se pierde en la etapa de producción.
Enviar mensaje RocketMQ siguiente código de ejemplo:
DefaultMQProducer mqProducer=new DefaultMQProducer("test");
// 设置 nameSpace 地址
mqProducer.setNamesrvAddr("namesrvAddr");
mqProducer.start();
Message msg = new Message("test_topic" /* Topic */,
"Hello World".getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
);
// 发送消息到一个Broker
try {
SendResult sendResult = mqProducer.send(msg);
} catch (RemotingException e) {
e.printStackTrace();
} catch (MQBrokerException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
sendEl método es una operación sincrónica, siempre y cuando este método no lanza ninguna excepción, en nombre del mensaje ha sido enviado con éxito .
El mensaje se ha enviado con éxito para el mensaje en nombre del único fin Broker, Broker en diferentes configuraciones, puede devolver un estado diferente en respuesta a:
SendStatus.SEND_OKSendStatus.FLUSH_DISK_TIMEOUTSendStatus.FLUSH_SLAVE_TIMEOUTSendStatus.SLAVE_NOT_AVAILABLE
descripciones de estado oficiales citadas:
Different broker figura terminal de por encima de configuración se explicará en detalle más adelante
Además RocketMQ también proporciona el modo de transmisión asíncrono, adaptada a tiempo, más sensible al tiempo de respuesta de la escena de negocios enlace.
DefaultMQProducer mqProducer = new DefaultMQProducer("test");
// 设置 nameSpace 地址
mqProducer.setNamesrvAddr("127.0.0.1:9876");
mqProducer.setRetryTimesWhenSendFailed(5);
mqProducer.start();
Message msg = new Message("test_topic" /* Topic */,
"Hello World".getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
);
try {
// 异步发送消息到，主线程不会被阻塞，立刻会返回
mqProducer.send(msg, new SendCallback() {
@Override
public void onSuccess(SendResult sendResult) {
// 消息发送成功，
}
@Override
public void onException(Throwable e) {
// 消息发送失败，可以持久化这条数据，后续进行补偿处理
}
});
} catch (RemotingException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
el envío de mensajes asíncronos se debe señalar que de anulación método de devolución de llamada, para comprobar el resultado de la transmisión en el método de devolución de llamada.
Si forma síncrona o asíncrona, se encontrará con problemas de red principales para enviar fracaso. En vista de esta situación, podemos establecer un número razonable de reintentos cuando los problemas de la red, puede intentar automáticamente. Ajuste de la siguiente manera:
// 同步发送消息重试次数，默认为 2
mqProducer.setRetryTimesWhenSendFailed(3);
// 异步发送消息重试次数，默认为 2
mqProducer.setRetryTimesWhenSendAsyncFailed(3);
0x02. Etapa de almacenamiento Broker
Por defecto, siempre y cuando el mensaje al terminal corredor preferentemente guardado en la memoria, y luego vuelve inmediatamente una respuesta de confirmación al productor. Entonces Broker lotes periódica de un grupo de mensajes asíncronos de la memoria al disco cepillo.
De esta manera la reducción de E / S veces, se puede lograr un mejor rendimiento, pero si el fallo de alimentación de la máquina se produce, el tiempo de inactividad y otras situaciones anormales, el mensaje no ha sido cepillo oportuna en el disco, aparecerá el caso de un mensaje perdido.
Para asegurar Broker cliente no pierde el mensaje, para garantizar la fiabilidad del mensaje, el mensaje que tenemos que modificar el mecanismo de sincronización para guardar en disco vías cepillo, el mensaje de discos de almacenamiento de éxito , devolverá una respuesta.
configuración de lado Broker modificado como sigue:
## 默认情况为 ASYNC_FLUSH
flushDiskType = SYNC_FLUSH
Si el Corredor no es el tiempo sincronizado dentro del cepillo de disco ( por defecto 5S ) placa de escobillas completa, volverá SendStatus.FLUSH_DISK_TIMEOUTal estado al productor.
implementación de clúster
Con el fin de garantizar la disponibilidad, Broker generalmente un maestro ( Maestro ) de múltiple ( Esclavo despliegue). Con el fin de garantizar que los mensajes no se pierden, el mensaje también necesita ser copiado al nodo esclavo.
Por el modo por defecto, el mensaje de escritura principal del éxito, puede devolver el reconocimiento al productor, entonces el mensaje se copia en el asíncrona esclavo nodo.
NOTA: La configuración maestro: flushDiskType = SYNC_FLUSH
En este punto, si el maestro de repente el tiempo de inactividad y no recuperable , no ha sido copiado al esclavo se perderá del mensaje.
Con el fin de mejorar aún más la fiabilidad del mensaje, podemos utilizar la replicación síncrona, Maestro nodo esperará a que la sincronización esclavo de replicación nodo es completa, volverá respuesta de confirmación.
Asíncrono y diferencias FIG replicación replicación síncrona son los siguientes:
Nota: Por favor, no se deje engañar en el mapa, corredor de copia maestra puede configurar una sola manera, sólo para explicar el concepto de replicación sincrónica y replicación asíncrona en el mapa.
nodo maestro de replicación Broker configurado como sigue:
## 默认为 ASYNC_MASTER
brokerRole=SYNC_MASTER
Si un esclavo nodo no está se devuelve la respuesta sincronizada dentro de un tiempo especificado, el productor recibirá un SendStatus.FLUSH_SLAVE_TIMEOUTestado de retorno.
resumen
Combinado fase de producción y etapa de almacenamiento, si es necesario estrictamente para asegurar que el mensaje no se pierde , las necesidades de los agentes para adoptar la configuración siguiente:
## master 节点配置
flushDiskType = SYNC_FLUSH
brokerRole=SYNC_MASTER
## slave 节点配置
brokerRole=slave
flushDiskType = SYNC_FLUSH
Al mismo tiempo, también necesitamos este proceso con los productores, para determinar si el estado de retorno es SendStatus.SEND_OK. Si otros estados, debemos tener en cuenta la compensación y vuelve a intentarlo.
Si bien la configuración anterior mejora la alta fiabilidad del mensaje, pero se reducirá el rendimiento , la práctica de producción requiere la selección completa.
0x03. Fase del consumo
Los consumidores tiran de mensaje desde el agente, y después realiza la lógica de servicio correspondiente. Una vez ejecutado con éxito, volverá a ConsumeConcurrentlyStatus.CONSUME_SUCCESSque el estado del corredor.
Si usted no recibe el consumo Broker acuse de recibo de otros estados, los consumidores se tire de la siguiente pieza de noticias de nuevo, vuelve a intentarlo. De tal manera para prevenir eficazmente el proceso anormal se produce el gasto del consumidor, o el mensaje se pierde en la transmisión de la red.
Código del Consumidor mensaje es el siguiente:
// 实例化消费者
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("test_consumer");
// 设置NameServer的地址
consumer.setNamesrvAddr("namesrvAddr");
// 订阅一个或者多个Topic，以及Tag来过滤需要消费的消息
consumer.subscribe("test_topic", "*");
// 注册回调实现类来处理从broker拉取回来的消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
// 执行业务逻辑
// 标记该消息已经被成功消费
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
// 启动消费者实例
consumer.start();
Más proceso de consumo de noticias, tenemos que prestar atención al estado del mensaje se devuelve . Sólo cuando la lógica de negocio real se ejecuta con éxito, podemos volver ConsumeConcurrentlyStatus.CONSUME_SUCCESS. De lo contrario, tenemos que volver atrás ConsumeConcurrentlyStatus.RECONSUME_LATERy vuelve a intentarlo más tarde.
0x04. Resumen
Después de leer el mensaje no se pierde el enfoque RocketMQ, de vuelta en este aspecto Kafka solía vivir , no se encuentra, los dos resueltos idea es la misma, la diferencia no es los mismos parámetros de configuración.
Así que la próxima vez, pedir al entrevistador cómo XX colas de mensajes para asegurar que el mensaje no se pierde? Si no ha utilizado la cola de mensajes, no llores, cara de la sonrisa de él, con calma dio su análisis que los pasos se perderán, y aproximadamente Solutions.
Por último, también podemos decirle a nuestro pensamiento, a pesar de la mejora de la fiabilidad del mensaje, pero el mensaje puede conducir a la retransmisión, el consumo repetido. Así que para los clientes de consumo, que deben tomarse para asegurar idempotencia .
Pero presta atención, a continuación, el entrevistador le puede decir el tema, vamos a hablar de cómo garantizar que idempotencia, debe decidir antes de decir oh.
¿Qué? ¿No sabe cómo alcanzar el poder y así sucesivamente? A continuación, centrarse rápidamente ** @ intérprete programa , hablaremos más adelante en el artículo idempotente ** este tema.
0x05. Referencia
- Time Geeks - clase de mensaje principal de colas
- https://github.com/apache/rocketmq/blob/master/docs/cn/best_practice.md
Una última palabra (la búsqueda de atención)
Caishuxueqian, es inevitable que habrá fallas, si usted encuentra el lugar equivocado, por favor deje un mensaje y me señaló, y modificarlos.
Gracias nuevamente por su lectura, que era la planta baja pequeña Heige , una herramienta aún no tiene mono calvo, el siguiente artículo vamos a conocer a ~
Doy la bienvenida a la atención del público número: programa intérprete, y conseguir empuje diaria seco. Si usted está interesado en el contenido de mi tema, puede centrarse en mi blog: studyidea.cn