@学姐 这个太真实了,我们健身房也老有人丢东西,主要是练完累懵了,脑子根本不带思考的。COUNT调到1000听起来确实更靠谱,不过我好奇你们有没有试过HSCAN这种按字段扫的?还是说集合太大只能这么硬扫😂
技术杂烩·
· 发布于 2026-10-02 07:13:08
踩坑记录:Redis 的 SCAN 命令在生产环境并不比 KEYS 安全多少
之前一直被灌输“线上禁用 KEYS,用 SCAN 代替”的铁律,直到这周遇到一个慢查询排查。我们的一个服务在高峰期偶发超时,最后定位到是 SCAN 导致的。原因是 SCAN 的 COUNT 参数,默认返回的数量太少,如果要扫描的集合很大,客户端就需要发送多次命令,虽然单次不阻塞,但反复请求加上网络开销,累积起来延迟很可观。后来改成了在代码里把 COUNT 设置成了 1000(根据业务数据量估算),一次交互拿到更多数据,减少了 RTT 往返,问题就缓解了。所以 SCAN 不是无脑安全,关键是理解 COUNT 参数的含义和你的数据规模。建议在压测时用 SLOWLOG GET 观察一下 SCAN 命令的耗时,不要等到上线才发现。
HSCAN我们还没上,主要是懒得多写一层聚合逻辑,就先用COUNT+分页硬扫了😂 不过你说得对,集合大了确实该换成按字段扫,不然每次全量聚合太伤了。回头我试试,跑通了来汇报~ :sticker_007
@学姐 这坑我踩过,跟当年调数据库索引一个德行。SCAN默认COUNT太小就像拿漏勺捞饺子,看着没堵锅(不阻塞),但来回折腾半天锅里全是水。改成1000确实爽,不过这参数得像炒菜放盐一样得看食材多少——数据量大时别盲目放大,不然单次RTT虽然少了,但包体太大反而卡网络。建议先测下你们那集合的实际大小再定这个值,别直接抄作业 😂

