Análisis de la arquitectura RocketMQ
Kafka confía en Zookeeper para la elección del clúster. En la misma posición que rocketMQ está NameServer. Este servidor de nombres es solo un servicio de registro y no tiene función de elección. Cada proxy está conectado al NameServer y mantiene el estado a través de latidos.
Los productores y consumidores acceden periódicamente a NamesServer para obtener información de los brokers y establecer conexiones con los brokers que utilizan. Este es exactamente el mismo sistema que los microservicios.
Entonces, ¿cómo funciona la elección de clústeres de rocketMQ? Funciona integrando Dledge, un paquete jar que implementa el algoritmo borrador.
Como se muestra en la figura, los temas se pueden fragmentar entre varios intermediarios, los productores pueden escribir datos en fragmentos inaccesibles y diferentes grupos pueden utilizar la información de los fragmentos.
Como se describe a continuación para el almacenamiento, rocketMQ puede configurar un sitio maestro y un sitio en espera para formar una replicación del sitio maestro y en espera.
http://rocketmq.apache.org/rocketmq/how-to-support-more-queues-in-rocketmq/ presenta el diseño inicial del almacenamiento Rocket MQ. A diferencia del almacenamiento Kafka, Kafka Data es. almacenado en cada partición, mientras que RocketMQ almacena centralmente los mensajes reales, la información de metadatos se almacena en messageQueue y CommitLog se puede indexar a través de la información de metadatos.
Los datos guardados se eliminan todos los días; si el disco está lleno y excede el umbral establecido, no se permite escribir datos.
RocketMQ está diseñado para garantizar el procesamiento concurrente de mensajes, pero a veces los mensajes tienen estado, es decir, secuenciales. Entonces, ¿cómo logra esto RocketMQ?
Se envía a un caché temporal y cuando se alcanza el tiempo de retraso, el servicio de retraso lo enruta al tema.
Si el consumo devuelve consumer_later, se retrasará durante un período de tiempo como el mensaje retrasado anterior, ingresará a la cola de mensajes inactivos, consumirá la cola de mensajes inactivos y luego será reprocesado.
Si la escala empresarial es pequeña y el código fuente no se cambiará, elija RabbitMQ; si la escala empresarial es grande y no se permite la pérdida de mensajes y se busca una alta eficiencia, utilice RocketMQ; Si la escala empresarial es grande y la cantidad de mensajes perdidos durante la operación es pequeña, use Kafka para un alto rendimiento, si se usa para big data, no hay duda de que Kafka es la opción;