Cómo utilizar correctamente los scripts de Lua de Redis para operaciones atómicas

Clasificar los scripts Lua de Redis de forma atómica

Los scripts de Lua de Redis ejecutan la lógica de datos específica directamente en el servidor Redis. Mientras se ejecuta un script, Redis no procesa ninguna otra actividad del servidor; por lo tanto, los comandos que contiene están aislados de otros clientes. De este modo, se pueden agrupar varios comandos sencillos en un operación atómica combinar, por ejemplo, una comprobación de límite seguida de una actualización del contador o un cargo solo si hay saldo suficiente.

Sin un script, un cliente puede, en primer lugar, leer un contador mediante GET, comprobar el límite en el código de la aplicación y, a continuación, enviar INCR. Sin embargo, entre estos pasos, otro cliente podría modificar ese mismo contador. Por el contrario, un script lee, comprueba e incrementa sin ese estado intermedio observable. Esto resuelve la condición de carrera de la regla compuesta, pero no resuelve automáticamente cuestiones como los valores límite adecuados, los tiempos de ejecución o los formatos de devolución.

«Aislado y aislado» no significa que Scripts de Lua para Redis Las transacciones de base de datos cuentan con una función de reversión automática. Si se produce un error de ejecución después de que ya se haya realizado una operación de escritura, los cambios anteriores no se revierten de forma generalizada. Por ello, los scripts deben comprobar los datos de entrada, los tipos de datos y los requisitos funcionales antes de la primera operación de escritura; las rutas de error tras los cambios requieren un tratamiento diseñado específicamente para ello.

Algunas reglas típicas son: permitir el acceso solo dentro de un límite o reducir un saldo solo si hay cantidad suficiente. Comprueba primero si un comando único de Redis ya expresa la regla completa. Un script resulta útil cuando varias operaciones de Redis, incluidas sus condiciones, deben interactuar de forma atómica.

Un patrón Lua para «comparar y borrar» compara el valor almacenado con un token de propiedad pasado como parámetro y solo lo borra si coinciden. De este modo, un proceso que se retrase no podrá borrar una clave que ya se haya reasignado solo por el hecho de tener un token antiguo.

Este modelo comparativo describe exclusivamente el orden seguro para una única clave de Redis. No resuelve cuestiones más amplias relacionadas con los bloqueos distribuidos, como las duraciones adecuadas de los leases, las pausas en los procesos, los fallos o la coordinación de varias instancias de Redis. Además, la atomicidad de un comando o script solo abarca los datos de Redis implicados, no el pago, la base de datos, el correo electrónico ni las API externas.

Lua Sandbox y límites claros

Redis Open Source incorpora Lua 5.1 para los scripts. Este entorno de ejecución no debe equipararse a una versión principal de Lua instalada localmente o actual: Redis determina el conjunto de funciones disponibles y las normas de seguridad. Por lo tanto, quien desarrolle scripts de Lua para Redis debería comprobarlos con la versión de Redis que se utilice realmente y no dar por sentadas las características de cualquier entorno externo de Lua.

La ejecución se lleva a cabo en una Sandbox con límites deliberadamente estrictos. Un script debe procesar datos de Redis y los argumentos que se le pasen, pero no debe utilizar ni el sistema de archivos, ni la red, ni los servicios del sistema operativo. Por lo tanto, las llamadas HTTP externas, el envío de mensajes o el acceso a archivos locales deben realizarse en el código de la aplicación o en un servicio destinado a tal fin, y no en el «cache scripting».

Redis ofrece KEYS y ARGV como variables de ámbito global. En cambio, para tus propios valores intermedios y funciones auxiliares, debes utilizar variables locales con local. De este modo, queda claro qué valores se aplican únicamente a esta llamada, y la lógica del script no genera dependencias evitables. Los comandos de Redis se ejecutan de forma específica mediante redis.call o redis.pcall en.

El entorno de pruebas no sustituye a la planificación de la capacidad. Durante su ejecución normal, un script bloquea el acceso de otros clientes al servidor, por lo que no son adecuadas las bucles largos, los volúmenes de datos ilimitados ni los cálculos que requieren un gran esfuerzo computacional. Limita el trabajo a unas pocas claves conocidas de antemano y a cálculos sencillos. Los análisis exhaustivos, los inventarios globales basados en SCAN o la comunicación con sistemas externos aumentarían los riesgos operativos sin ampliar de forma significativa la atomización.

Entender EVAL, KEYS y ARGV

La ejecución directa de un script se realiza mediante el formato EVAL script numkeys [key …] [arg …]. Según el código fuente, «numkeys» determina cuántos de los parámetros siguientes son claves. El script accede a ellos a través de KEYS con indexación basada en uno; el resto de valores se encuentran en ARGV. Esta distinción es fundamental: las claves describen los datos de Redis, mientras que los argumentos representan las entradas específicas, como el valor límite, la cantidad o el token esperado.

Por ejemplo, un script de límite recibe el contador como KEYS[1] y el valor máximo como ARGV[1]. Lee el estado actual, convierte el valor límite con tonumber(ARGV[1]) lo convierte en un número y compara ambos valores antes de incrementarlo. La conversión deja clara la regla numérica prevista, en lugar de basarse en un tratamiento implícito de los valores de los argumentos. Si falta un contador, el script puede tratar específicamente el valor leído como cero.

Cada clave que el script lea o escriba debe especificarse previamente como argumento de clave. Componer nombres de clave en el script a partir de prefijos o derivarlos de datos almacenados no es una práctica recomendable. Redis, especialmente en el caso de Redis Open Source con el clúster activado, no puede determinar antes de la ejecución qué datos necesita el script. Por lo tanto, pasa las claves conocidas en su totalidad mediante KEYS y los valores variables exclusivamente mediante ARGV.

En Redis Open Source con el clúster activado, las claves pasadas a un script deben encontrarse además en la misma ranura de hash. La declaración anterior permite realizar esta comprobación, pero no la sustituye. Para datos relacionados entre sí, puede resultar útil elegir deliberadamente una etiqueta de hash, por ejemplo: account:{4711}:balance y account:{4711}:reservations. La parte entre llaves determina aquí la asignación de ranuras; las claves determinadas dinámicamente socavarían esta planificación.

Actualizar de forma atómica el contador de ventana fija

El siguiente ejemplo es un Contador de ventana fija para una instancia de prueba local. Comprueba el valor del contador y el límite en una sola ejecución del servidor y establece el tiempo de vencimiento únicamente tras el primer acceso correcto dentro de la ventana de tiempo. De este modo, se elimina el intervalo de tiempo entre una llamada GET en el código de la aplicación y una posterior llamada INCR, durante el cual otro cliente podría modificar el contador.

La llamada pasa la clave del contador, el límite y la duración de la ventana en segundos. El estado 1 significa «aprobado», el estado 0 significa «límite alcanzado». El estado 2 indica una entrada no válida detectada en las comprobaciones previas, un valor de contador de cadena rechazado en dichas comprobaciones o la existencia de un contador de cadena sin TTL. Si la clave contiene otro tipo de datos de Redis, la llamada GET ya falla con un error técnico de tipo; en ese caso, el script no devuelve el estado 2. También hay que distinguir otros errores de tiempo de ejecución de Redis del estado de retorno técnico. El ejemplo no es una plantilla para datos de acceso, límites en producción ni pruebas de carga.

Antes de cada operación de escritura, el script comprueba que todos los números sean números enteros positivos finitos dentro de un límite máximo deliberadamente bajo. Esto es más que una simple comprobación con tonumber: Valores como 1.5 o 1e3 se rechazan. Además, el límite de un millón impide que la precisión numérica de Lua o la de INCR La cadena de números enteros esperada puede resultar relevante fuera del ámbito del ejemplo. La duración máxima de la ventana, de 86.400 segundos, también limita la EXPIRE Número de segundos facilitado.

EVAL "local max_counter = 1000000; local max_window = 86400; local function positive_integer(value, maximum) if type(value) ~= 'string' or not string.match(value, '^%d+$') then return nil; end; local number = tonumber(value); if not number or number ~= math.floor(number) or number < 1 or number > maximum then return nil; end; return number; end; local limit = positive_integer(ARGV[1], max_counter); local window = positive_integer(ARGV[2], max_window); if not limit or not window then return {2, 'invalid-arguments'}; end; local raw = redis.call('GET', KEYS[1]); if raw and (type(raw) ~= 'string' or not string.match(raw, '^%d+$')) then return {2, 'invalid-counter'}; end; local current = raw and tonumber(raw) or 0; if not current or current ~= math.floor(current) or current < 0 or current > max_counter then return {2, 'invalid-counter'}; end; if raw and redis.call('TTL', KEYS[1]) == -1 then return {2, 'missing-ttl'}; end; if current >= limit then return {0, current}; end; local next = redis.call('INCR', KEYS[1]); if next == 1 then redis.call('EXPIRE', KEYS[1], window); end; return {1, next}" 1 demo:rate-limit 3 60

La expresión regular solo admite dígitos decimales; a continuación, la función auxiliar comprueba el valor numérico, si es un número entero y el límite máximo. Un contador ya existente solo puede ser un número entero no negativo dentro del mismo intervalo limitado. De este modo, un valor negativo, fraccionario o excesivamente grande no puede alterar la semántica de los límites sin que se detecte. Solo tras estas comprobaciones se lleva a cabo INCR.

Si la clave no existe, el script comienza en 0. Si ya existe un contador de cadenas válido sin fecha de caducidad, devuelve el estado 2 y no escribe nada. Tras el primer INCR establece EXPIRE el TTL, que se ha comprobado previamente en su totalidad. En caso de coincidencias posteriores, este permanece sin cambios, por lo que la ventana no se amplía continuamente.

El Contrato de devolución forma parte de la interfaz: el primer elemento de la matriz describe el estado; el segundo proporciona, en función del estado, el valor del contador o un código de error. El código que realiza la llamada debería tratar un rechazo técnico con el estado 0 de forma diferente al estado 2, que indica que no se cumple un requisito previo. Para obtener más información sobre la selección y el seguimiento de los tiempos de ejecución, consulte el artículo Analizar y optimizar la caducidad de las claves de Redis una base complementaria.

El TTL se establece aquí deliberadamente solo en la primera coincidencia. Un patrón que se renovara en cada acceso tendría una semántica temporal diferente y ya no sería una «ventana fija». Atomicidad en Lua Solo elimina la condición de carrera. El algoritmo elegido, y no el lenguaje de scripting, es el que determina si «Fixed Window», «Sliding Window» o «Token Bucket» se adapta a la equidad y a la distribución de la carga deseadas.

Seleccionar el modelo de atomización adecuado

No todos los requisitos compuestos requieren un script. Si existe un único comando de Redis que ya exprese la regla de negocio en su totalidad, suele ser más sencillo de ejecutar y comprobar. En cambio, en el caso de las reglas de varios niveles, es necesario tener en cuenta conjuntamente las condiciones, los tipos de datos y el contrato de retorno.

A partir de Redis Open Source 8.4, existen operaciones nativas «Compare-and-Set» y «Compare-and-Delete» para claves de tipo cadena individuales: SET admite las opciones de comparación IFEQ/IFNE/IFDEQ/IFDNE; DELEX se encarga de la eliminación condicional. Por lo tanto, en los casos de claves individuales que cumplan los criterios, no es necesario utilizar un script de comparación propio. En Redis 8.2, 8.0 y 7.x, estas nuevas opciones de SET y DELEX no están disponibles; en esos casos, siguen siendo válidos los patrones WATCH o Lua adecuados.

Para un «Compare-and-Set» optimista, WATCH puede ser adecuado antes de MULTI y EXEC: si una clave observada cambia antes de EXEC, la transacción se cancela y el cliente decide si vuelve a intentarlo. Además, las transacciones no ofrecen una reversión general en caso de errores durante la fase EXEC. Por lo tanto, WATCH sigue siendo una opción cuando la condición necesaria no puede representarse mediante un único comando nativo.

Los scripts EVAL están vinculados a la caché de scripts y reciben sus entradas a través de KEYS y ARGV. Funciones de Redis A partir de Redis 7.0, existen como bibliotecas con nombre: se registran con FUNCTION LOAD, se invocan con FCALL y se persisten y replican junto con la base de datos. Sus claves y argumentos llegan a la función como parámetros; de ahí se deriva un modelo de implementación e invocación diferente al de EVAL.

Por lo tanto, EVAL es una opción ideal para lógica sencilla orientada a aplicaciones. La presencia de varios clientes y una lógica de datos que se mantiene a largo plazo suelen ser argumentos a favor de las funciones, siempre que la versión de código abierto de Redis utilizada las admita. Además, la decisión debería tener en cuenta la implementación, los permisos, la gestión de errores y un valor de retorno claramente documentado, y no solo el número de comandos de Redis.

Clústeres, errores y contratos de devolución

En Redis Open Source con el clúster activado, las claves pasadas en un script de varias claves deben estar en el mismo slot de hash. Las etiquetas de hash permiten controlar esto: En account:{4711}:balance y account:{4711}:reservations El contenido entre llaves determina el slot. Por lo tanto, ambas claves pueden consultarse conjuntamente. El requisito de «mismo slot» se aplica también a las operaciones con varias claves y a las transacciones MULTI/EXEC que se analizan aquí. Otras configuraciones de producto y de clúster pueden variar en el caso de comandos concretos. De ello no se deriva una autorización general de «cross-slot» para Lua: la documentación sobre múltiples claves clasifica EVAL/EVALSHA como una operación de «single-slot», incluso en Redis Software con el clúster activado y con o sin la API de clúster OSS.

Todas las claves utilizadas deben declararse como argumentos de clave antes de su llamada. Un script no debe derivar los nombres de las claves a partir de valores almacenados ni componerlos de forma dinámica. Esta regla permite a Redis realizar una comprobación correcta de las ranuras antes de la ejecución y evita dependencias ocultas que pasan desapercibidas en una instancia independiente, pero que provocan errores en Redis Open Source con el clúster activado.

Con redis.call() Cualquier error del comando Redis ejecutado se transmite al cliente como un error de script. redis.pcall() En cambio, lo devuelve a Lua para que el script pueda gestionarlo de forma específica. pcall solo tiene sentido si se ha definido una reacción específica, como una respuesta de error bien estructurada o un flujo alternativo válido. Ignorar los errores en silencio oculta problemas de datos e integridad.

A Contrato viciado distingue entre errores técnicos y resultados funcionales. WRONGTYPE significa, por ejemplo, que el tipo de datos almacenado en Redis no se ajusta al comando esperado y debe investigarse. Por el contrario, una reserva rechazada por falta de existencias es un resultado esperado y puede devolver, por ejemplo, el estado y las existencias restantes. Las aplicaciones no deben tratar estas categorías de la misma manera ni repetirlas ambas de forma generalizada.

Garantizar un funcionamiento estable de la distribución de scripts

EVAL Es adecuado para llamadas directas: el cliente transmite el código fuente completo de Lua junto con los valores de las claves y los argumentos. En el caso de un script que se utilice con frecuencia y no sufra modificaciones, la aplicación puede, en su lugar, utilizar SCRIPT LOAD cargarlo en la caché de scripts. Redis devuelve un resumen SHA1 para ello; EVALSHA A continuación, ejecuta exactamente el código fuente correspondiente. Esto evita tener que realizar la transferencia repetidamente, pero no altera ni la atomicidad ni la responsabilidad técnica del script.

El Caché de scripts no es permanente. Tras un reinicio, una conmutación por error o SCRIPT FLUSH una llamada mediante resumen se puede realizar con NOSCRIPT fallar. La aplicación debería gestionar este caso de forma habitual: recargar el script y repetir la llamada válida, siempre que la propia lógica de reintento lo permita. Por lo tanto, un «digest» no debe interpretarse como una garantía de que el script ya esté presente en todos los servidores de destino.

En el caso de las tuberías, esta opción de reserva está limitada. Si ya se han enviado varios comandos juntos, la aplicación puede encontrar un NOSCRIPT- No sustituir los errores de forma retroactiva cargando y volviendo a ejecutar el código en el mismo punto. Redis recomienda, para estos casos, el uso de EVAL como estrategia alternativa. Quien tenga previsto implementar la replicación y la conmutación por error debería comprender, además, qué papel desempeña el búfer de replicación a la hora de volver a conectar una réplica: Comprender el backlog de replicación de Redis.

Las variables no deben incluirse en el código fuente de Lua, sino en ARGV. De lo contrario, cada valor límite generaría un script diferente y aumentaría innecesariamente el tamaño de la caché. Desde Redis 7.4, se puede utilizar EVAL o EVAL_RO los scripts cargados se eliminan al alcanzar el límite de la caché según el principio LRU; esto no sustituye ni la parametrización ni el tratamiento de NOSCRIPT.

Dominar los guiones largos y los errores ortográficos

Un script de Lua bloquea otras actividades del servidor durante su ejecución normal. Esto proporciona aislamiento, pero cuando la ejecución se prolonga, se convierte en Riesgo operativo. Si un script supera el límite configurado busy-reply-threshold, Redis responde a los comandos normales con BUSY; no detiene el script automáticamente. Por eso, limita los scripts a unas pocas claves conocidas y a cálculos pequeños y limitados.

Las operaciones de escritura previas a un error o a un bucle infinito son especialmente críticas. Si un script ya ha modificado datos, puede SCRIPT KILL no se cierre correctamente. Por eso, comprueba los datos introducidos antes de la primera escritura y evita los bucles sin límite, así como SCAN sobre el conjunto de datos. Las pruebas deben reflejar el volumen de datos y las rutas de error de la implementación prevista.

En memoria máxima El proceso depende de la primera operación de escritura. Si Redis ya ha superado el límite, un comando que consuma mucha memoria puede, en redis.call interrumpir el script; redis.pcall Devuelve el error a Lua y requiere una ruta de gestión de errores diseñada específicamente. Los cambios ya realizados no se revierten con esta operación.

Una primera operación que no requiere memoria adicional, como por ejemplo DEL o LREM, en cambio, puede dejar que el script siga ejecutándose; las operaciones de escritura posteriores pueden aumentar el consumo a través de maxmemory aumentar. Errores técnicos como WRONGTYPE o CROSSSLOT En Redis Open Source, con el clúster activado, se requieren correcciones en el modelo de datos o en el diseño de claves, mientras que solo el propio script puede definir un rechazo técnico como estado estable.

Elegir deliberadamente los casos de uso adecuados

En el caso de una reserva condicional, un script puede comprobar el stock, rechazar un valor demasiado bajo y, si la operación se realiza con éxito, devolver el stock restante. El Reserva atómica Sin embargo, solo incluye Redis. Los pagos, la base de datos relacional, el correo electrónico y las API externas requieren una coordinación específica y, en su caso, una lógica de compensación.

La elección depende de la versión de Redis y del modelo de datos. A partir de Redis Open Source 8.4, las opciones de comparación de SET una asignación condicional y DELEX se encarga de comparar y eliminar una clave de cadena concreta. Antes de Redis 8.4 o en el caso de una condición más compleja, WATCH con MULTI/EXEC Una alternativa: si una clave observada cambia antes de EXEC, la transacción se interrumpe y el cliente decide si volver a leer y repetir. Un breve script en Lua resulta adecuado cuando varias órdenes o estructuras de datos, incluidas sus reglas de negocio, deben interactuar en el lado del servidor.

En el caso de los bloqueos distribuidos, ni el comando individual ni el patrón Lua son suficientes como concepto global. La duración del arrendamiento, las pausas de proceso, las interrupciones, las repeticiones, la conmutación por error y los escenarios con múltiples instancias deben evaluarse por separado. Da preferencia a un comando nativo si la versión utilizada y su semántica cubren toda la regla. De lo contrario, WATCH y valorar la conveniencia de utilizar un script breve en función de la tolerancia a errores y la ubicación de la lógica de negocio. Para la lógica reutilizable del lado del servidor, una función de Redis puede ser una buena opción. Scripts de solo lectura A partir de Redis 7.0, se pueden utilizar a través de EVAL_RO o EVALSHA_RO funcionan, pero solo si se garantiza que la lógica no implica escritura.