¿Cuál elegir entre RocketMQ y Kafka?
1. Escenarios aplicables
Kafka es adecuado para el procesamiento de registros
Rocketmq es adecuado para el procesamiento empresarial
Conclusión: no hay diferencia entre los dos, dependiendo de la decisión comercial específica
2. Rendimiento
Se dice que el TPS de escritura en una sola máquina de Kafka es de un millón de entradas por segundo
rocketmq es aproximadamente 100.000 entradas/segundo
Conclusión: en términos de rendimiento, Kafka tiene un mayor rendimiento en una sola máquina
3. Fiabilidad
Kafka utiliza vaciado de disco asíncrono y Replicación asíncrona
rocketmq admite vaciado de disco asíncrono/sincrónico, replicación asíncrona/sincrónica
Conclusión: el método de sincronización admitido por rocketmq mejora la confiabilidad de los datos
4. Rendimiento en tiempo real
Kafka y Ambos soportes de rocketmq realizan encuestas largas y los mensajes de rocketmq son más en tiempo real
Conclusión: rocketmq gana
5. Número de colas admitidas
Kafka tiene más de 64 máquinas individuales Cola/partición, el rendimiento del envío de mensajes se reduce gravemente
Rocketmq admite hasta 5 W de colas en una sola máquina, con un rendimiento estable
Conclusión: a largo plazo, rocketmq gana,
6. Secuencia de mensajes
Bajo ciertas configuraciones de Kafka, la secuencia de mensajes es compatible, pero cuando un Broker deja de funcionar, los mensajes estarán desordenados
rocketmq admite una secuencia de mensajes estricta después de que el Broker deja de funcionar, el envío de mensajes fallará, pero no estará desordenado
Conclusión: rocketmq gana
p>
7. Mecanismo de reintento de falla de mensaje
El consumo de Kafka falla. No se admite el reintento.
La falla de consumo de Rocketmq admite reintentos programados y el intervalo entre cada reintento se pospone.
8. Mensajes programados/retrasados
Kafka no admite mensajes programados
rocketmq admite mensajes programados
9. Mensajes de transacciones distribuidas
Kafka no admite mensajes de transacciones distribuidas
rocketmq lo admitirá en el futuro
10. Mecanismo de consulta de mensajes
Kafka no admite consultas de mensajes
rocketmq admite la consulta de mensajes según la identificación del mensaje y también admite la consulta de mensajes según el contenido del mensaje
11. Rastreo de mensajes
Kafka puede rastrear mensajes según el desplazamiento
rocketmq admite el rastreo de mensajes según el tiempo, como volver a consumir mensajes de una determinada hora y minuto de hace un día
p>Pregunta 1: modos push y pull
Modo push: después de que el cliente establece una conexión con el servidor, cuando el servidor tiene un mensaje, el mensaje se envía al cliente
Modo pull: el cliente sondea continuamente y solicita al servidor que obtenga nuevos mensajes
En una implementación específica, tanto el modo push como el pull adoptan el método de extracción activo del consumidor, es decir, el sondeo del consumidor Extrae mensajes del corredor
Diferencia:
En el método push, el consumidor encapsula el proceso de sondeo y registra el oyente MessageListener. Después de recibir el mensaje, despierta al consumidorM de MessageListener.
mensaje a consumir. Para los usuarios, sienten que el mensaje ha sido enviado.
En el método pull, el proceso de obtención del mensaje debe ser escrito por el usuario. Primero, se obtiene la colección MessageQueue. el tema que se pretende consumir y se recorre la colección de MessageQueue. Luego, obtenga los mensajes en lotes para cada MessageQueue. Después de recuperarlos una vez, registre el desplazamiento inicial de la cola que se recuperará a continuación hasta que finalice la recuperación. MessageQueue
Pregunta: Dado que todos se implementan mediante el método pull, ¿cómo garantiza rocketmq la naturaleza en tiempo real de los mensajes?
Sondeo largo: rocketmq se implementa mediante sondeo largo, lo que significa que durante el proceso de solicitud, si los datos del lado del servidor no se actualizan, la conexión se suspenderá hasta que el servidor envíe Nuevos datos y luego regrese. y luego ingrese el ciclo
El cliente solicita datos del servidor como un sondeo tradicional. El servidor bloqueará la solicitud y no regresará inmediatamente hasta que haya datos o se agote el tiempo de espera del cliente. y luego enviar una nueva solicitud al servidor después de que el cliente procese la información de respuesta