RocketMQ, contraste kafka y RabitMQ

efecto de cola de mensajes MQ

desacoplamiento

El desacoplamiento es la cola de mensajes para resolver los problemas más esenciales.

La consistencia final

consistencia eventual se refiere al estado de los dos sistemas consistentes, ya sea éxito o fracasan. Algunos cola de mensajes no puede garantizar la consistencia eventual.

radiodifusión

Message Queue funciones esenciales que pueden ser emitidas. Con la cola de mensajes, sólo tenemos que estar preocupados acerca de si la cola de entrega de mensajes, en cuanto a quién le gustaría suscribirse, aguas abajo de las cosas, sin duda, en gran medida reducir la carga de trabajo del desarrollo y el FBI.

Pico de desplazamiento y control de flujo

Un escenario de uso típico es el servicio de clipping de pico para la escena de tráfico.

Debido al espacio limitado, este artículo se centra en un número relativamente cola de mensajes, por favor refiérase a los escenarios de recortes detallado modelo de flujo de embudo: "¿Cuál es el pico recorte de tráfico? ¿Cómo resolver el servicio de clipping escena pico "

RocketMQ, contraste kafka y RabitMQ

propiedad	ActiveMQ	RabbitMQ	RocketMQ	Kafka
lenguaje de desarrollo	Java	Erlang	Java	Scala
Stand-alone Rendimiento	mil diez	mil diez	100 000	100 000
oportunidad	nivel ms	clase nosotros	nivel ms	MS nivel dentro
la gestión de clusters			nombre del servidor	cuidador del zoológico
alta disponibilidad	High (arquitectura maestro-esclavo)	Alta (arquitectura maestro-esclavo) reflejando el modo de implementar, no será un cuello de botella cuando grandes volúmenes de datos	Muy alta (arquitectura distribuida)	Muy alta (arquitectura distribuida)
Desde el maestro de conmutación		La conmutación automática, la primera unirse al clúster se convertirá en el maestro esclavo, porque los datos antes de que el esclavo recién agregado no lo hace maestro de sincronización, por lo que habrá algunos datos pueden perderse.	No es compatible con el cambio automático, no se puede enviar un mensaje al maestro después de fallo del maestro, los consumidores probablemente años 30 (por defecto) percibe este evento, después de lo cual el consumo de esclavos; si el maestro no puede ser restaurado, puede haber algo de la información se pierde la replicación cuando asíncrono	La conmutación automática, N copias, permite que el fallo N-1; fracaso después de maestro esclavo seleccionar automáticamente desde un principal
el rendimiento de escritura de mensajes		RAM RocketMQ de alrededor de 1/2, 1/3 DISCO RAM acerca de las propiedades de rendimiento.	Bueno, 10 bytes por prueba, autónomo único corredor de 7w / s, solo 3broker sobre 12w / s	Muy bien, cada 10 bytes pruebas: un millón / s
características	producto maduro, la compañía ha estado en muchas aplicaciones, hay más documentos; apoyar mejor a una variedad de protocolos	Basado en el desarrollo de Erlang, por lo que la competencia concurrente, excelente rendimiento, baja latencia, rica interfaz de gestión.	MQ cuenta con una más completa, mejor escalabilidad	MQ sólo es compatible con funciones importantes como dar marcha atrás consultas de mensajes y otras funciones no previstas, utilizar una amplia gama de escena de grandes volúmenes de datos.

为啥RabbitMQ能做到us级，其他的都是ms级呢？

主要有以下几个原因。

erlang语言天然支持高并发。
基于内存镜像模式实现，RabbitMQ的us级主要指基于RAM模式。

RocketMQ、KafKa和RabitMQ选择

Kafka

Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。

大型公司建议可以选用，如果有日志采集功能，肯定是首选kafka了。

RocketMQ

天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。

RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ。

RabbitMQ

RabbitMQ，结合erlang语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护。

如何保证消息的一致性和如何进行消息的重试机制？

如何保证消息的一致性

保证消息的一致性有三种方式。

定时补偿+幂等消费(TCC)
推拉结合
分布式事务

如何进行消息的重试机制

下面只分析RocketMQ的消息重试。

RocketMQ只有当消费模式为集群模式时，Broker才会自动进行重试，对于广播消息是不会重试的。消费者从Broker拉取消息失败时，RocketMQ会通过消息重试机制重新投递消息，这肯定不会一直投递。当投递到最大重试次数之后，就会加入到死信队列，我们只要对死信队列的数据做人工补偿。

认定为消费失败规则

RocketMQ规定，以下三种情况统一按照消费失败处理并会发起重试。

业务消费方返回ConsumeConcurrentlyStatus.RECONSUME_LATER
业务消费方返回null
业务消费方主动/被动抛出异常

注意对于抛出异常的情况，只要我们在业务逻辑中显式抛出异常或者非显式抛出异常，broker 也会重新投递消息，如果业务对异常做了捕获，那么该消息将不会发起重试。因此对于需要重试的业务，消费方在捕获异常的时候要注意返回 ConsumeConcurrentlyStatus.RECONSUME_LATER 或 null 并输出异常日志，打印当前重试次数。（推荐返回ConsumeConcurrentlyStatus.RECONSUME_LATER）

个人不建议捕获异常，让MQ认定为失败。

RocketMQ重试时间窗口

messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

死信的业务处理方式

默认的处理机制中，如果我们只对消息做重复消费，达到最大重试次数之后消息就进入死信队列了。

我们也可以根据业务的需要，定义消费的最大重试次数，每次消费的时候判断当前消费次数是否等于最大重试次数的阈值。

如：重试三次就认为当前业务存在异常，继续重试下去也没有意义了，那么我们就可以将当前的这条消息进行提交，返回 broker 状态ConsumeConcurrentlyStatus.CONSUME_SUCCES，让消息不再重发，同时将该消息存入我们业务自定义的死信消息表，将业务参数入库，相关的运营通过查询死信表来进行对应的业务补偿操作。

RocketMQ 的处理方式为将达到最大重试次数（16 次）的消息标记为死信消息，将该死信消息投递到 DLQ 死信队列中，业务需要进行人工干预。实现的逻辑在 SendMessageProcessor 的 consumerSendMsgBack 方法中，大致思路为首先判断重试次数是否超过 16 或者消息发送延时级别是否小于 0，如果已经超过 16 或者发送延时级别小于 0，则将消息设置为新的死信。死信 topic 为：%DLQ%+consumerGroup。

发送失败如何重试

设置生产者在 3s 内没有发送成功则重试 3 次的代码如下。

   /**同步发送消息，如果 3 秒内没有发送成功，则重试 3 次*/
    DefaultMQProducer producer = new DefaultMQProducer("DefaultProducerGroup");
    producer.setRetryTimesWhenSendFailed(3);
    producer.send(msg, 3000L);

参考

https://www.jianshu.com/p/fec054f3e496
https://gitbook.cn/books/5d340810c43fe20aeadc88db/index.html