Caso 1: Log del follower corto respecto al lider (XLen relevante)
Optimización XLen
Cuando el log del seguidor es más corto que el índice consultado por el líder, el seguidor rechaza informando su longitud total (XLen). Esto permite al líder saltar de inmediato al final del log del seguidor sin necesidad de decrementar de a uno.
10
11
12
13
Tráfico de Red (RPC)
S1
L*
ENTRIES
Progreso de SincronizaciónnextIndex[S1] = 13
Caso 2: Conflicto de Término (Líder NO lo tiene, XIndex relevante)
Algunas consideraciones a tener en cuenta:
¿Porqué usamos XIndex, si cuando buscamos el término en el log del lider podemos parar justo en el término mas chico y guardar ese índice? (Ejemplo: Animación caso A paso 5, paramos la busqueda en el líder encontrando un término mas chico -4- con índice 10)
OJO, porque si bien a simple vista parece funcionar para este caso, NO SIRVE como regla general para todos los casos.
Contraejemplo:
Inicio idx 10 => F: [2,5,5,5] - L: [2,3,4,6] Llega un comando al lider en el término 6 en el índice 14, resolvé AppendEntries y fijate que no funciona la regla :)
Para pensar...
Tenemos que buscar un término (número) en un 'arreglo' ordenado de forma creciente... ¿Conocemos algún algoritmo de busqueda mejor que O(n)? Imagino que sí...
¿Pero, vale la pena la implementacion? ¿Vamos a tener que recorrer n filas hacia atrás para buscar un término?... (Spoiler: No - Snapshots)
10
11
12
13
Tráfico de Red (RPC)
S3
L*
ENTRIES
Progreso de SincronizaciónnextIndex[S3] = 13
Caso 3: Conflicto de Término (Líder SÍ lo tiene, XTerm relevante)
Para pensar...
Tenemos que buscar un término (número) en un 'arreglo' ordenado de forma creciente... ¿Conocemos algún algoritmo de busqueda mejor que O(n)? Imagino que sí...
¿Pero, vale la pena la implementacion? ¿Vamos a tener que recorrer n filas hacia atrás para buscar un término?... (Spoiler: No - Snapshots)