/tags/elasticache/ Recent content in elasticache on Hugo -- gohugo.io en Wed, 04 Nov 2026 23:20:00 +0800 /posts/redis-legacy-cache-key-cleanup/ Wed, 04 Nov 2026 23:20:00 +0800 /posts/redis-legacy-cache-key-cleanup/ 一个服务改写了它的 Redis 缓存。新代码写的 key 是 my-service:users:v1:<id> 这种带服务名和版本号的小写名字，每个都设了 TTL；旧代码按 Users:<id>、ApiKeys:<key> 这样的名字写，没有 TTL，不会过期。新版本上线之后没有代码再读这些旧 key，它们只占内存。ApiKeys: 更麻烦一些：key 名就是原始 API key，值是对应的 secret。 这次要在测试环境把它们删掉。那里的 Redis 是一台自建的单节点 Redis 7.4.2，几个服务共用，各自占一个 database 号，所以删除有两个要求：只删这个服务的旧 key，删的过程不能让同节点的其他服务变慢。下面几节都在这台单机上做；同样的步骤放到 ElastiCache 和 cluster 模式上要改哪些地方，放在最后一节。 先确认旧 key 没人读、这个库里没有别的服务 删缓存不会丢数据，数据源在数据库里，缓存没了会重新加载。要防的是两种情况：还有进程在读写这些 key，或者这个库里混着别的服务的 key。 前一种看部署。测试环境只剩新版本的一个 Pod，滚动更新留下的旧 Pod 都已经退出，新版本的代码里也搜不到任何一个旧名字。 后一种要从两头核对。应用配置里写着 host 和 database 号，Redis 那边则用 CLIENT LIST 看实际连着谁，它会列出每个连接所在的库和客户端库的名字。筛出这个库上的连接： rcli() { redis-cli -h "$REDIS_HOST" --no-auth-warning "$@"; } rcli CLIENT LIST | tr -d '\r' | grep ' db=3 ' | tr ' ' '\n' \ | grep -E '^(db|lib-name|lib-ver|age|idle|cmd)=' | paste -sd' ' - age=32321 idle=10 db=3 cmd=info lib-name=Lettuce(spring-data-redis_v4.