En Zookeeper, la consistencia de datos distribuidos se logra principalmente mediante el protocolo ZAB.
El protocolo ZAB se divide en dos partes:
- Difusión de mensajes
- Recuperación tras caída
Difusión de mensajes
Zookeeper utiliza un único proceso líder (Leader) para recibir y procesar todas las solicitudes de transacciones de los clientes, y adopta el protocolo de transmisión atómica del protocolo ZAB para difundir las solicitudes de transacciones como propuestas (Proposal) a todos los nodos Follower. Cuando más de la mitad de los servidores Follower del clúster envían una confirmación (ACK) correcta, el Leader vuelve a enviar un mensaje de confirmación (commit) a todos los servidores Follower para confirmar la propuesta. Este proceso puede denominarse brevemente confirmación de transacciones 2PC. El flujo completo se puede ver en la siguiente figura. Tenga en cuenta que los nodos Observer solo se encargan de sincronizar los datos del Leader y no participan en el proceso de sincronización de datos 2PC.
Recuperación tras caída
En condiciones normales, el modo de difusión de mensajes funciona bien, pero una vez que el servidor Leader sufre una caída, o si por razones de red el servidor Leader pierde la comunicación con más de la mitad de los Follower, se entra en el modo de recuperación tras caída y es necesario elegir un nuevo servidor Leader. Durante este proceso pueden aparecer dos riesgos de inconsistencia de datos, que deben evitarse mediante las características del protocolo ZAB.
- 1. El servidor Leader se bloquea inmediatamente después de enviar el mensaje de confirmación (commit).
- 2. El servidor Leader se bloquea inmediatamente después de proponer una propuesta (proposal).
El modo de recuperación del protocolo ZAB utiliza las siguientes estrategias:
- 1. Elegir el nodo con el zxid más grande como nuevo líder (leader).
- 2. El nuevo líder procesa los mensajes aún no confirmados en el registro de transacciones.
El próximo capítulo explica en detalle el proceso de elección del líder (leader).