캐시 갱신 뒤 TTL이 없어지는 문제와 EVALSHA의 CROSSSLOT은 같은 오류가 아닙니다. 하나는 값 변경 시 만료 정보의 계약이고, 다른 하나는 스크립트가 접근하는 키들의 클러스터 배치 조건입니다. pipeline으로 바꿨다는 이유만으로 두 계약이 보존되지는 않습니다.
예시 키 세 개의 슬롯 계산 결과
Python 표준 라이브러리의 CRC16 계산으로 user:{42}:a와 user:{42}:b는 모두 8000, user:{43}:a는 3937이었습니다. Redis Cluster 해시 태그 규칙에 따라 비어 있지 않은 중괄호 내부를 해시한 결과입니다. 실제 Redis 노드에 요청한 결과는 아닙니다.
import binascii
print(binascii.crc_hqx(b"42", 0) % 16384)
print(binascii.crc_hqx(b"43", 0) % 16384)같은 태그로 관련 키를 모을 수 있지만 모든 키에 한 태그를 붙이면 특정 슬롯에 부하가 집중됩니다. 스크립트의 KEYS 목록과 실제 접근 키를 확인하고, 서로 관련 없는 계정의 키를 한 원자 작업에 섞을 필요가 있는지 먼저 검토하세요.
TTL은 값 갱신의 별도 계약이다
SET 문서의 KEEPTTL은 기존 만료를 유지하는 옵션입니다. 새 키에 자동으로 기본 TTL을 만들어 주는 기능은 아닙니다. 읽은 TTL이 -2인지, -1인지, 양수인지 구분하고, “키가 없을 때 생성”과 “기존 키 갱신”의 정책을 따로 정해야 합니다.
스테이징에서는 존재하는 만료 키·영구 키·없는 키와 같은 슬롯·다른 슬롯을 조합해 시험합니다. 중간 실패가 있는 pipeline은 Lua와 같은 원자성을 보장하지 않습니다. NOSCRIPT는 스크립트 캐시 문제로 CROSSSLOT과 별개입니다. 이번 계산은 키 배치 규칙만 확인했으며 Redis에서 만료 보존이나 원자성을 실행 검증하지 않았습니다.