Cómo implementar bloqueo distribuido (2016)

Cómo implementar bloqueo distribuido

• En el sitio web de Redis se encontró el algoritmo Redlock, que afirma implementar un bloqueo distribuido tolerante a fallas sobre Redis.
• Ya existen varias implementaciones independientes de Redlock, y como puede haber personas que dependan de este algoritmo, el autor decidió compartir sus notas.
• Redis es útil para compartir entre servidores datos temporales y que cambian rápidamente, pero preocupa extenderlo al ámbito de gestión de datos que requiere consistencia fuerte y durabilidad.

El propósito del bloqueo

• Un bloqueo sirve para garantizar que solo uno de varios nodos ejecute una tarea específica.
• Si el bloqueo se usa por eficiencia, puede ser mejor usar una sola instancia de Redis.
• Si el bloqueo se usa por exactitud, Redlock no es adecuado.

Proteger recursos con un bloqueo

• Un bloqueo en un sistema distribuido es distinto de un mutex en una aplicación multihilo.
• Evita que otro cliente realice la misma operación mientras un cliente lee un archivo, lo modifica y luego lo vuelve a escribir.

Implementar un bloqueo seguro mediante fencing

• Se puede implementar un bloqueo seguro usando tokens de fencing e incluyéndolos en las solicitudes de escritura.
• Redlock no es seguro porque no tiene una función para generar tokens de fencing.

Usar el tiempo para lograr consenso

• A diferencia de los algoritmos en el modelo asíncrono, Redlock hace muchas suposiciones sobre el tiempo.
• Si el reloj del sistema funciona de manera extraña, la expiración de la clave puede ocurrir antes o después de lo esperado.

Romper las suposiciones temporales de Redlock

• Redlock asume un modelo de sistema síncrono y solo funciona correctamente cuando la latencia de red, las pausas de proceso y los errores de reloj son limitados.
• Casos como el incidente de GitHub con 90 segundos de retraso de paquetes pueden poner en riesgo la seguridad de Redlock.

Conclusión

• Redlock es innecesariamente pesado para bloqueos orientados a optimizar eficiencia y no es lo suficientemente seguro para situaciones que requieren exactitud.
• Si se necesita un bloqueo por exactitud, es mejor usar un sistema de consenso adecuado, como ZooKeeper.

Resumen de GN⁺

• El algoritmo Redlock aporta una discusión importante sobre cómo implementar bloqueos en sistemas distribuidos.
• Este artículo destaca los supuestos temporales y los problemas de seguridad en sistemas distribuidos, y explica la importancia de implementar correctamente los bloqueos.
• Recomienda sistemas alternativos como ZooKeeper y ayuda a comprender la complejidad de los sistemas distribuidos.

[GN⁺]

Comentarios de Hacker News

• He implementado bloqueo distribuido usando Temporal y hasta ahora ha funcionado bien. Aprovechar las capacidades de Temporal hace que la implementación del bloqueo distribuido sea sencilla.
• Dejé un comentario en el blog diciendo que se pasó por alto un punto importante del algoritmo, y señalé que por eso su rechazo se basa en un punto débil.
• Con computadoras y APIs modernas se puede esperar durante intervalos de tiempo aproximados; las pausas de GC son limitadas y los relojes monotónicos funcionan. Es una suposición aceptable.
• Criticar el mecanismo de liberación automática y criticar el objetivo del algoritmo y el modelo del sistema son problemas distintos.
• Redlock se ha usado con éxito en varios casos de uso, y si se configuran correctamente los timeouts es difícil provocar condiciones de carrera. Configurar timeouts demasiado pequeños es un error de diseño.
• Estoy actualizando mis conocimientos de bajo nivel y de algoritmos, y quiero construir algo por diversión, pero la mayoría del material es de nivel juguete o extremadamente complejo.
• Implemento bloqueo distribuido usando PostgreSQL: inicio una transacción, obtengo un advisory lock y mantengo el bloqueo hasta que la transacción se libera.
• Me di cuenta de que no había verificado el estado de la conexión a la base de datos, y si no era una operación relacionada con la base de datos, podría haber perdido el bloqueo.
• Implementé bloqueo distribuido con Deno y Deno KV, que se basan en FoundationDB.
• Revisé Redis, pero resolví el problema de corrección usando PostgreSQL y convirtiendo las solicitudes en operaciones SET.
• A muchos ingenieros no les importan los problemas de corrección, y existen casos límite en los que los mensajes pueden perderse o llegar en el orden incorrecto.
• Establecer un timeout para un bloqueo es una buena idea, y si el cliente falla, el SO o el supervisor liberan el bloqueo.
• Cuando no se necesita un bloqueo, se pueden usar tokens de versión para mantener la integridad de los datos. Se pueden usar valores únicos como un UUID.