¿Cómo es correcta esta configuración en el algoritmo Raft?
Entonces supongamos que la configuración del registro para 3 servidores en el algoritmo Raft es la siguiente:
S1 -> 3
S2 -> 3 3 4
S3 -> 3 3 5
Esta configuración puede surgir si, digamos, S3 es el líder en el término 3 y la entrada se ha confirmado en todas las réplicas. Luego, en otra operación del cliente con el mismo líder S3, solo se logra replicar la entrada en S2 y en sí mismo, y luego se produce un fallo. Después de eso, S2 gana la elección con votos de sí mismo y S1. Obtiene una entrada y la ingresa en el registro, y luego se produce un fallo. S3 vuelve y luego recibe el voto de S1 y de sí mismo y se convierte en líder, ingresa otro registro en el término 5 y luego se produce un fallo.
Ahora nos encontramos en una situación en la que las entradas en los términos 4 y 5 definitivamente no están confirmadas. Digamos que S2 vuelve a convertirse en líder (recibiendo el voto de sí mismo y de S1). Intentará corregir los registros en los seguidores y terminaría sobrescribiendo y añadiendo a ambos seguidores para obtener:
S1 -> 3 3 4
S2 -> 3 3 4
S3 -> 3 3 4
En mi razonamiento, es razonable eliminar el registro en el término 5 porque es posible que el líder no haya respondido con un mensaje “done” al cliente, ya que la replicación de la entrada en el término 5 no se realizó en la mayoría de los servidores. Pero ¿no es el mismo argumento válido para la entrada en el término 4? Y si es así, ¿por qué se replica en todos los lugares? El cliente tampoco habría recibido una respuesta “done” para la entrada en el término 4, por lo que el cliente pensaría que la máquina de estado no ejecutaría esta operación, pero mediante la lógica anterior lo hace.
¿Alguien puede explicarlo, por favor?
davy.ai
Basándose en el escenario dado, la configuración del registro para los 3 servidores en el algoritmo Raft es inconsistente. Las entradas en el término 4 y 5 definitivamente no están confirmadas, y es posible que el líder que hizo las entradas no haya respondido con un mensaje de “hecho” al cliente.
En cuanto a la pregunta de por qué la entrada en el término 4 está replicada en todas partes pero la entrada en el término 5 no lo está, es esencial entender el concepto de consenso en el algoritmo Raft.
El consenso requiere que cada entrada que esté confirmada en el registro de un líder eventualmente se replique en los registros de todos los demás servidores del clúster. Esto asegura que cada servidor tenga la misma vista del estado del sistema y sea seguro confirmar las entradas en la máquina de estado.
En el escenario dado, la entrada en el término 4 se ha replicado en todas partes porque fue confirmada antes de que el líder (S3) se estrellara. Sin embargo, la entrada en el término 5 no se replicó en la mayoría de los servidores, por lo tanto, no se considera confirmada.
Por lo tanto, de acuerdo con los principios fundamentales de consenso en el algoritmo Raft, sería justo eliminar la entrada del registro del término 5. La entrada en el término 4, por otro lado, se considera confirmada y debe replicarse en todos los servidores para garantizar la consistencia.