1. Principio de implementación de RocketMQ
2. ¿Por qué escribir NameServer sin Zk?
1. NameServer está escrito por usted mismo, lo cual es conveniente para la expansión y la descentralización. Mientras exista un NameServer, se puede usar todo el entorno del centro de registro.
2. La elección Zk debe cumplir con más de la mitad del mecanismo antes de poder usarse.
Tres, cuatro métodos de clúster:
1. Un solo nodo maestro: la presión de carga es muy grande y los datos pueden perderse si está inactivo
2. Múltiples etapas maestras: datos de almacenamiento compartido, pero si no hay un nodo esclavo, los datos pueden perderse cuando la máquina está inactiva
3, múltiples maestros y el nodo múltiple Slave, implementado en los datos del formulario sincronización desde el maestro de sincronización, el mensaje se almacena en el productor principal volverá a la sincronización a la espera Broker volverá al mensaje de acuse de entrega exitosa ack
4, y una pluralidad de multi-maestro nodo esclavo, implementado en forma de sincronización de datos asíncrona desde el maestro , El productor almacena el mensaje en el maestro, devuelve un acuse de recibo para confirmar que el mensaje se entregó correctamente y se sincroniza asincrónicamente con el intermediario en espera, lo cual es muy eficiente, pero los datos pueden perderse
4. ¿Se verá afectado el uso del corredor cuando se expanda el corredor? ¿Se puede reducir?
No, debido a que el productor realiza el almacenamiento de datos a través del sondeo a través del número de nodos registrados en el NameServer, el número de nodos no se escribe muerto
Se puede reducir, pero la premisa es que los mensajes en el Broker deben ser consumidos
Quinto, la diferencia entre RocketMQ y Kafka
| RocketMQ | Kafka | |
|---|---|---|
| Centro de registro | Zookeeper | Nombre del servidor |
| Corredor | Concepto lógico, un corredor es igual a múltiples combinaciones maestras | Concepto físico, un corredor es un |
| Noticias de transacciones | Apoyo | |
| Mensaje secuencial | Apoyo | Un Brocker corresponde a un consumidor para lograr mensajes secuenciales. |
6. ¿Cómo aumentar el rendimiento de RocketMQ en la versión independiente?
Solo es necesario agregar colas y consumidores
Siete, las ideas centrales de Rocketmq para resolver transacciones distribuidas
1. El productor envía a nuestro Broker (lado del servidor MQ) nuestro mensaje de despacho para que sea un semi-mensaje, y este mensaje no puede ser consumido por los consumidores.
2. Al ejecutar nuestra transacción local, envíe o revierta el resultado de la transacción de ejecución local al Broker
3. Si el Broker obtiene el resultado de la transacción local si se envía, configure el medio mensaje para que el consumidor pueda consumirlo, si la transacción local Si la ejecución falla, elimine el medio mensaje directamente del Broker
4. Si nuestra transacción local no notifica a nuestro Broker del resultado de manera oportuna, entonces nuestro Broker tomará la iniciativa de consultar regularmente (60s por defecto) los resultados de la transacción local
5. El resultado de la transacción local es en realidad un método de devolución de llamada, que encapsula el resultado de la transacción local de acuerdo con su propio escenario comercial
En este momento, las transacciones locales deben usar transacciones manuales, con anotaciones, la transacción no es fácil de controlar
Ocho, RabbitMQ resuelve los defectos de los problemas de transacciones distribuidas
RabbitMQ resuelve el problema de las transacciones distribuidas. Si la cola de reabastecimiento también se suspende, los datos del pedido pueden perderse, pero el pedido puede enviarse con éxito y luego debe compensarse manualmente.
Nueve, la idea central de resolver transacciones distribuidas
1. Consistencia final
2. Asegurar el éxito de la primera transacción
Diez, el trasfondo de las transacciones distribuidas
rpc llama de forma remota la comunicación entre múltiples servicios diferentes para garantizar la coherencia de los datos. Existen múltiples fuentes de datos. Las transacciones de cada fuente de datos no se afectan entre sí.
11. Otros
La versión independiente de RocketMQ, por defecto, se divide en cuatro colas en un tema, el propósito es un alto rendimiento
Broker contiene temas, los temas incluyen colas
Kafka tiene copia de seguridad
Kafka es una partición, un corredor tiene múltiples particiones
RocketMQ es una cola, un corredor tiene múltiples colas
El número de colas en RocketMQ debe ser el mismo que el número de consumidores.
¿Cómo implementan los tres mqs mensajes secuenciales?
¿Cómo se agrupan?
lcn ya no se mantiene, y ahora usa principalmente seata
RocketMQ ha experimentado la prueba del doble 11
escrito en lenguaje java, entiendo que el código fuente es fácil de expandir y mantener
RocketMQ es una actualización de kafka
9876 es el número de puerto predeterminado de NameServer
Los productores deben estar agrupados, de lo contrario se informará un error
Si los consumidores están en el mismo grupo, solo un consumidor consumirá el mismo mensaje
Características de RocketMQ
1. Mensajes de transacciones de soporte
2. Mensajes secuenciales de soporte
3. Los consumidores admiten el filtrado de etiquetas para reducir la transmisión de ancho de banda
4. Escritura en lenguaje Java, fácil de expandir y mantener
5. RocketMQ ha experimentado la prueba del doble 11
NameServer: similar a eureka para el registro y descubrimiento de servicios, la información del productor, el consumidor y el tema se almacenan en NameServer. Descentralizado Obtenga conciencia dinámica, evite el tiempo de inactividad y modifique la dirección.
Intermediario: servidor MQ
Productor: Productor
Consumidor: Consumidor
brokerid = 0 es el nodo maestro> 0 como el nodo esclavo
aparato se vuelve dominante cambiar manualmente
