El clúster RabbitMQ experimenta una partición de red y una posible pérdida de datos
Debido a la búsqueda de alta disponibilidad, las colas del clúster generalmente se configuran como colas duraderas, diferidas y reflejadas.
Supongamos que el clúster RMQ tiene cinco nodos: nodo[1:5]
Supongamos que la cola ? q? es una cola maestra y una cola esclava, y que los procesos de la cola están ubicados en el nodo1 y el nodo3.
Antes de particionar:
Suponga que los procesos maestro y esclavo de la cola ? q están ubicados en los nodos: nodo 1 y nodo 3, nodo 2, nodo 4 y nodo 5. En este momento, la red entre ellos está paralizada
La comunicación de red entre los dos aún no se ha restablecido. Es probable que este estado intermedio conduzca a la pérdida de datos. El análisis específico es el siguiente:
El cliente productor n.° 1 que anteriormente llegó al nodo 1 y al nodo 3 puede continuar enviando mensajes a la cola q normalmente.
El cliente productor n.º 2 en los nodos 2, 4 y 5 no sabe que la cola q no está en el subgrupo de nodos actual (no hay procesos de cola q en el subgrupo). Las colas se diferencian de Exchange y Bindings en que el proceso de cola solo existe en su nodo maestro y en sus nodos esclavos. Las colas se diferencian de Exchange y Bindings en que los procesos de cola solo existen en sus nodos maestro y esclavo. En este momento, incluso si el productor usa mecanismos como confirmar y returnListener, el mensaje aún no puede llegar a la cola de destino q (especialmente si el flujo ascendente se envía a través de intercambio y hay varias colas colgadas debajo), pero el remitente aún puede recibir el Ack devuelto por el servidor Indica que el paquete se ha enrutado a la cola de destino mediante conmutación. Esto resultará en la pérdida de paquetes.