Editar:Ahora, con el código actualizado, creo que su metodología es fundamentalmente defectuosa, aparte de lo que está informando.
La forma en que lo implementó requiere ejecutar KEYS en producción - esto es malo. A medida que escala, provocará una carga de bloqueo del sistema creciente e innecesaria en el servidor. Como dice cada parte de la documentación, no usar keys en producción. Tenga en cuenta que codificar el tiempo de caducidad en el nombre de la clave no le proporciona ningún beneficio. Si convirtió esa parte del nombre de la clave en la marca de tiempo de creación, o incluso en un número aleatorio, nada cambiaría. De hecho, si quitaras ese bit, nada cambiaría.
En cambio, una ruta más sensata sería usar un nombre de clave que no dependa del tiempo. El uso de caducidad maneja esa función por usted. Llamemos a su cosa de tarifa limitada una "sesión". Su nombre de clave sin la marca de tiempo es el "ID de sesión". Al establecer una caducidad de 60 s, ya no estará disponible en la marca de 61 s. Por lo tanto, puede incrementar y comparar de forma segura el resultado con su límite sin necesidad de conocer la hora actual o la hora de vencimiento. Todo lo que necesita es un nombre de clave estático y una caducidad adecuada.
Si INCR una clave inexistente, Redis devolverá "1", lo que significa que creó la clave y la incrementó en un solo paso/llamada. así que básicamente la lógica es así:
- crear ID de "sesión"
- incrementar el contador usando ID
- comparar resultado para limitar
- si cuenta ==1, establezca la caducidad en 60 s
- recuento de id> límite, rechazo
El paso 3.1 es importante. Un conteo de 1 significa que esta es una clave nueva en Redis y desea establecer su vencimiento en ella. Cualquier otra cosa significa que la caducidad ya debería haberse establecido. Si lo configura en 3.2, interrumpirá el proceso porque conservará el contador durante más de 60 segundos.
Con esto, no necesita tener nombres de clave dinámicos basados en el tiempo de vencimiento y, por lo tanto, no necesita usar keys para averiguar si existe una "sesión" existente para el objeto de velocidad limitada. También hace que su código sea mucho más simple y predecible, además de reducir los viajes de ida y vuelta a Redis, lo que significa que tendrá una menor carga en Redis y un mejor rendimiento. En cuanto a cómo hacer eso con la biblioteca del cliente que está usando, no puedo decirlo porque no estoy tan familiarizado con eso. Pero la secuencia básica debería ser traducible ya que es bastante básica y simple.
Sin embargo, lo que no ha mostrado es algo que respalde la afirmación de que el vencimiento no está ocurriendo. Todo lo que ha hecho es mostrar que se le está indicando a Redis y estableciendo una fecha de caducidad. Para respaldar su reclamo, debe demostrar que la clave no caduca. Lo que significa que debe mostrar la recuperación de la clave después del tiempo de vencimiento y que el contador no se "restableció" al volver a crearse después del vencimiento. Una forma en que puede ver que está ocurriendo el vencimiento es usar notificaciones de espacio de teclas. Con eso, podrá ver a Redis diciendo que una clave caducó.
Donde este proceso fallará un poco es si hace varias ventanas para limitar la velocidad, o si tiene una ventana mucho más grande (es decir, 10 minutos), en cuyo caso los conjuntos ordenados pueden ser una opción más sensata para evitar la carga anticipada de solicitudes. - Si es deseado. Pero como está escrito su ejemplo, lo anterior funcionará bien.
