Cuando varios workers PHP pueden ejecutar a la vez una tarea sobre el mismo recurso, un bloqueo puede reducir el trabajo duplicado. Es habitual plantearlo para generar un informe, procesar un pedido o actualizar un recurso compartido. Pero usar Redis no convierte por sí solo una operación en consistente: el proceso puede pausarse, el bloqueo puede caducar y otro worker puede empezar antes de que termine el primero.
La decisión importante no es solo cómo crear una clave, sino qué propiedad debe protegerse y qué sistema puede hacerla cumplir. En muchos casos, una restricción única o una transacción de base de datos ofrece una garantía más directa. Los bloqueos distribuidos con Redis en PHP son útiles cuando coordinan procesos que no pueden resolverse con una única operación atómica en la base de datos, siempre que se diseñen como una protección temporal y no como la fuente definitiva de verdad.
Qué resuelve un bloqueo distribuido y qué no garantiza
Un bloqueo distribuido permite que varios procesos, posiblemente en servidores distintos, compitan por una exclusión temporal. Si un worker adquiere el bloqueo, los demás deberían abstenerse de entrar en la sección crítica mientras siga vigente. Esto resulta útil, por ejemplo, para evitar que dos procesos inicien simultáneamente una tarea costosa o coordinar un trabajo que afecta a servicios externos.
El bloqueo no garantiza por sí mismo que solo exista una escritura, que el proceso propietario siga vivo ni que Redis y la base de datos mantengan un estado coherente. Es una concesión temporal, parecida a un lease. Si el worker se detiene durante más tiempo que su duración, Redis puede permitir que otro adquiera el bloqueo aunque el primero continúe trabajando al reanudarse.
Por eso, una aplicación no debería depender exclusivamente de la clave de Redis para proteger una regla de negocio. La operación final debe tener sus propias defensas: validaciones, restricciones de integridad, control de versiones o idempotencia, según el caso.
Cuándo usar Redis y cuándo elegir la base de datos
Antes de añadir un bloqueo, identifica la condición que se quiere preservar. Si se trata de impedir que una entidad tenga dos registros con el mismo identificador, una restricción única en la base de datos expresa y hace cumplir esa regla en el punto donde se escriben los datos. No depende de que todos los workers respeten un protocolo externo.
Si varios cambios deben confirmarse juntos, una transacción puede ser suficiente. Para evitar sobrescribir una actualización concurrente, puede encajar el control optimista: leer una versión, actualizar solo si no ha cambiado y tratar el conflicto de forma explícita. En operaciones sobre filas o conjuntos de datos, el bloqueo pesimista de la propia base de datos puede ser más apropiado, aunque su alcance y duración deben limitarse.
Redis puede ser una buena opción cuando la exclusión coordina trabajo entre procesos y no existe una sola operación de base de datos que lo resuelva, o cuando se necesita evitar que muchos workers inicien a la vez una tarea repetida. Evalúa también si el coste de esperar, reintentar y operar Redis está justificado. Si una clave única resuelve el problema con menos componentes, suele ser preferible.
Adquisición atómica, propietario único y expiración
La adquisición debe ser una única operación atómica: crear la clave solo si no existe y asignarle una expiración en la misma operación. En Redis, el patrón habitual utiliza SET con las opciones equivalentes a “solo si no existe” y un tiempo de vida. Separar la creación de la clave y la asignación de expiración abre una carrera: el proceso podría fallar entre ambas y dejar un bloqueo sin vencimiento.
El valor de la clave debe ser un token único generado para ese intento, no un valor constante compartido por todos los workers. El token permite identificar al propietario y evita que un proceso elimine por error el bloqueo adquirido después por otro. El cliente PHP debe considerar adquirido el bloqueo únicamente si Redis confirma que la operación condicional tuvo éxito.
// Esquema conceptual; adapta la llamada a la biblioteca Redis utilizada.
$token = generarTokenUnico();
$adquirido = redisSetSiNoExisteConExpiracion($clave, $token, $duracion);
if (!$adquirido) {
// No entrar en la sección crítica.
}La expiración debe superar la duración esperada del trabajo, pero no ser tan larga que una caída deje a otros procesos esperando innecesariamente. No existe una cifra universal: mide la duración real, considera sus variaciones y define qué hacer con trabajos que se acercan al límite. Renovar una concesión también exige comprobar que el token sigue siendo el propietario; una renovación ciega podría prolongar el bloqueo de otro worker.
Liberación segura y riesgos de expiración
No elimines la clave con un borrado simple al terminar. Si el bloqueo original caducó y otro proceso adquirió uno nuevo, el primer worker podría borrar la clave del segundo. La liberación debe comparar el valor almacenado con el token del propietario y eliminar la clave solo si coinciden, como una operación atómica. Puede implementarse mediante un script ejecutado en Redis o una primitiva equivalente que compare y borre sin intercalar operaciones.
Incluso con adquisición y liberación correctas, una pausa larga del proceso puede producir escrituras concurrentes. El worker A adquiere el bloqueo, queda suspendido y su lease vence; B lo adquiere y escribe; A se reanuda y también escribe. Aún peor, una partición o un fallo de conexión puede dejar al cliente sin saber si la operación de adquisición se ejecutó.
Si una escritura tardía puede causar daños, el recurso protegido debe rechazarla de forma independiente. Una estrategia es usar un número de cercado o versión creciente y exigir que el sistema que recibe la escritura descarte valores antiguos. Ese contador debe tener las propiedades de orden y durabilidad que requiere el caso; un contador de Redis sin considerar reinicios o failover no debe asumirse automáticamente como garantía. Otra opción es verificar una versión en la base de datos dentro de la propia operación de escritura.
Sección crítica, contención y fallos de adquisición
Mantén dentro del bloqueo solo el trabajo que realmente requiere exclusión. Evita incluir llamadas lentas a servicios externos, esperas de usuario o procesamiento independiente. Cuanto más dure la sección crítica, más suben la contención y la posibilidad de superar el tiempo de expiración. Si el trabajo puede dividirse, separa la coordinación breve de las tareas que no dependen del estado compartido.
Cuando no se obtiene el bloqueo, no conviene reintentar indefinidamente ni ocupar workers PHP con esperas largas. Define una política según la importancia del trabajo: abandonar y registrar el conflicto, reintentar con espera limitada o enviar la tarea a una cola para procesarla después. El reintento debe ser seguro e idempotente, y el sistema debe distinguir una contención normal de un fallo de Redis.
Ante una conexión incierta, no des por hecho que el bloqueo se adquirió ni que no se adquirió. Diseña el flujo para recuperarse sin ejecutar dos veces una acción irreversible: por ejemplo, usa claves de idempotencia en la operación de negocio y consulta su resultado antes de repetirla.
Pruebas y señales operativas
Prueba el comportamiento con varios workers y controla las intercalaciones, no solo el caso feliz. Incluye escenarios en los que el proceso termina antes de liberar, la expiración ocurre durante el trabajo, Redis no responde y un worker antiguo intenta liberar después de que otro haya adquirido el bloqueo. Verifica que el token impide borrar una clave ajena y que las escrituras tardías se rechazan cuando la aplicación exige esa garantía.
En producción, observa adquisiciones fallidas, duración de las secciones críticas, expiraciones, renovaciones, errores de conexión y reintentos. Una tasa creciente de contención puede indicar que la granularidad del bloqueo es demasiado amplia o que hay más trabajo del necesario dentro de él. Las expiraciones frecuentes durante tareas normales señalan que el tiempo de concesión o el diseño del proceso requieren revisión, no simplemente un aumento automático del TTL.
Lista de comprobación para decidir
- ¿Qué regla de negocio se protege y puede expresarse con una restricción o transacción en la base de datos?
- ¿La adquisición es atómica, condicional y acompañada por una expiración?
- ¿Cada intento tiene un token único y la liberación compara propietario antes de borrar?
- ¿Qué ocurre si el proceso se pausa más que el lease o Redis pierde la conexión?
- ¿El sistema que recibe la escritura puede rechazar versiones antiguas o duplicados?
- ¿Hay una política limitada de espera, reintento y recuperación, además de métricas y pruebas de concurrencia?
Redis aporta coordinación temporal, no una garantía universal de consistencia. Úsalo cuando el problema realmente requiera coordinar procesos distribuidos, y conserva la protección definitiva en el sistema que escribe el dato. Si la regla puede imponerse de forma más simple en la base de datos, empieza por ahí.
