Bloqueos distribuidos y leases de líder: expiración, fencing tokens y lo que un bloqueo no puede garantizar

Qué es

Un bloqueo distribuido es un lease: un cliente adquiere el derecho exclusivo sobre un nombre durante un tiempo acotado y debe renovarlo antes de que expire. La documentación de Kubernetes (citada) describe los objetos Lease del grupo de API coordination.k8s.io, que se usan para los heartbeats de los nodos y para la elección de líder de los componentes del plano de control. Redis documenta Redlock (citado) como un algoritmo de bloqueo con varias instancias que propone, invita a que se analice y, en su aviso sobre consistencia, indica que deberían implementarse fencing tokens y que Redis no usa un reloj monótono para la expiración de claves.

El análisis de Kleppmann (citado) establece el punto central: un cliente puede detenerse (recolección de basura, fallos de página, contención de CPU, un paquete retrasado) después de adquirir el lease; el lease expira, un segundo cliente lo adquiere, y el primero se reanuda y escribe como si aún tuviera el bloqueo. Ningún servicio de bloqueo puede evitarlo por sí solo. La solución es un fencing token: un número que aumenta cada vez que se concede el bloqueo y que se envía con cada escritura al recurso protegido, el cual rechaza toda escritura con un token inferior a alguno que ya haya visto. El zxid o la versión de un znode de ZooKeeper pueden servir como ese token; Kleppmann señala que Redlock no tiene ningún mecanismo para generarlo.

Por qué importa

Kleppmann distingue los bloqueos por eficiencia (evitar hacer dos veces el mismo trabajo costoso; un duplicado ocasional es inocuo) de los bloqueos por corrección (un duplicado corrompe datos o cobra dos veces). Con frecuencia los equipos despliegan el primer tipo y confían en él como si fuera el segundo.

Cómo aplicarlo

• Decide qué tipo de bloqueo necesitas. Para eficiencia basta con un único almacén de bloqueos con TTL y un token de propietario al liberar.
• Para corrección, obtén del servicio de bloqueo un token monótonamente creciente (la revisión de un almacén de consenso, o una secuencia de base de datos actualizada en la misma transacción) y haz que el recurso lo verifique: una columna fence con un UPDATE ... SET fence = $held WHERE fence <= $held condicional (si no se actualiza ninguna fila, el lease se perdió), o una API de almacenamiento con escrituras condicionales.
• Fija el intervalo de renovación muy por debajo de la duración del lease y detén el trabajo de inmediato si falla una renovación; no "termines primero el elemento actual".
• Libera solo con el token que posees, para que un titular cuyo lease expiró no pueda liberar el del sucesor.
• Es preferible hacer idempotente el trabajo que bloquearlo; así el bloqueo solo reduce el esfuerzo desperdiciado.

Trampas

Las duraciones de los leases son suposiciones basadas en el reloj de pared sobre cuánto puede detenerse un proceso, y las pausas no tienen un límite superior. Un bloqueo que protege un recurso sin verificar un token es una pista, no una garantía. Un ejecutor de cron singleton cuya regla de que "solo se ejecuta una instancia" se impone mediante un bloqueo sigue necesitando tareas idempotentes.