Edit:Agora, com o código atualizado, acredito que sua metodologia é fundamentalmente falha, além do que você está relatando.

Do jeito que você implementou, você precisa executar KEYS em produção - isso é ruim. À medida que você expande, estará causando uma carga de bloqueio de sistema crescente e desnecessária no servidor. Como cada parte da documentação diz, não use keys em produção. Observe que codificar o tempo de expiração no nome da chave não oferece nenhum benefício. Se você transformasse essa parte do nome da chave no registro de data e hora de criação, ou mesmo em um número aleatório, nada mudaria. De fato, se você removesse esse bit, nada mudaria.

Uma rota mais sensata seria usar um nome de chave que não dependa do tempo. O uso de expiração lida com essa função para você. Vamos chamar sua coisa de taxa limitada de "sessão". Seu nome de chave sem o carimbo de data/hora é o "ID da sessão". Ao definir uma expiração de 60s nele, ele não estará mais disponível na marca de 61s. Assim, você pode incrementar e comparar com segurança o resultado ao seu limite sem precisar saber a hora atual ou o tempo de expiração. Tudo o que você precisa é de um nome de chave estática e um conjunto de expiração apropriado.

Se você INCR uma chave inexistente, o Redis retornará "1", o que significa que criou a chave e a incrementou em uma única etapa/chamada. então basicamente a lógica é assim:

1. criar ID de "sessão"
2. contador de incrementos usando ID
3. comparar resultado com limite
   1. se contagem ==1, defina a expiração para 60s
   2. contagem de id> limitar, rejeitar

O passo 3.1 é importante. Uma contagem de 1 significa que esta é uma nova chave no Redis e você deseja definir sua expiração nela. Qualquer outra coisa significa que a expiração já deve ter sido definida. Se você configurá-lo em 3.2, você interromperá o processo porque preservará o contador por mais de 60s.

Com isso, você não precisa ter nomes de chaves dinâmicas com base no tempo de expiração e, portanto, não precisa usar keys para descobrir se existe uma "sessão" existente para o objeto de taxa limitada. Ele também torna seu código muito mais simples e previsível, além de reduzir as viagens de ida e volta para o Redis - o que significa que ele terá uma carga menor no Redis e terá um desempenho melhor. Sobre como fazer isso com a biblioteca cliente que você está usando, não posso dizer porque não estou familiarizado com isso. Mas a sequência básica deve ser traduzível para ela, pois é bastante básica e simples.

O que você não mostrou, no entanto, é algo para apoiar a afirmação de que a expiração não está acontecendo. Tudo o que você fez foi mostrar que o Redis está realmente sendo informado e definir uma expiração. Para apoiar sua reivindicação, você precisa mostrar que a chave não expira. O que significa que você precisa mostrar a recuperação da chave após a expiração e que o contador não foi "reiniciado" ao ser recriado após a expiração. Uma maneira de ver que a expiração está acontecendo é usar as notificações de keyspace. Com isso, você poderá ver o Redis dizendo que uma chave expirou.

Onde esse processo falhará um pouco é se você fizer várias janelas para limitar a taxa ou se tiver uma janela muito maior (ou seja, 10 minutos), caso em que os conjuntos classificados podem ser uma opção mais sensata para evitar o carregamento antecipado de solicitações - se desejado. Mas como seu exemplo está escrito, o acima funcionará bem.