Dado que estás haciendo un '...' es difícil decirlo con seguridad, pero diría que estás configurando mykey durante esa parte, lo que eliminará efectivamente la caducidad.
From the EXPIRE manual
El tiempo de espera solamente se borra cuando se retira la llave utilizando el comando DEL o se sobrescribe el uso de los comandos set o GetSet
Also, regarding the -1 reply from TTL
Valor de retorno
Respuesta entera: TTL en segundos o -1 cuando la clave no tiene existe o no tiene un tiempo de espera excedido.
EDIT: Tenga en cuenta que este comportamiento cambió en Redis 2,8
A partir de Redis 2.8 El valor de retorno en caso de error cambió:
El comando devuelve -2 si no existe la clave .
El comando devuelve -1 si la clave existe pero no tiene expire asociado.
En otras palabras, si su clave existe, parecería ser persistente, es decir, no tener ningún conjunto de caducidad.
EDITAR: Parece que puedo reproducir esto si creo la clave en un servidor esclavo REDIS, el esclavo no eliminará la clave sin la entrada maestra, ya que normalmente no crearía claves localmente en un esclavo. ¿Este es el caso aquí?
Sin embargo, mientras que los esclavos conectados a un maestro no expirará teclas independiente (pero esperará a que el DEL procedente del maestro), que van a tomar todavía el estado completo del expira existente en el conjunto de datos , por lo tanto, cuando un esclavo es elegido para un maestro podrá caducar las llaves de forma independiente, actuando completamente como maestro.
Gracias por su respuesta tan rápida. El '...' en mi fragmento solo significaba que esperaba 20 segundos hasta que el TTL regresara -1. No escribo ningún comando aquí. Entonces la expiración debería ir hasta el final, ¿no? – user1151446
@ user1151446 Ver mi edición. –
gracias Joachim! Ese es exactamente el punto, involuntariamente configuré mi llave en el esclavo en lugar del maestro, lo cual es inconsistente. Si cambio a mi maestro todo funciona bien. – user1151446