Redis SISMEMBER性能优化：多键Lua脚本与批量方案对比

你的当前方案问题在哪 #

你现在用逗号拼接键传Lua再拆分的方式，有两个明显的坑：

1. 字符串拆分纯纯浪费性能：Redis本来就支持用KEYS数组直接传键，你非要拼接成字符串再拆，平白多了字符串解析的开销，要是键里碰巧有逗号，直接就解析出错了。
2. 哪怕你脚本里做了命中即返回的逻辑，这种键的传递方式也会拖慢脚本执行速度，是没必要的性能损耗。

单脚本优化vs分批执行 #

先把单脚本改对 #

先修正键的传递方式：直接把所有要检查的集合键丢进KEYS数组，userId用ARGV[1]传递。脚本逻辑就是遍历KEYS，每查一个集合就判断，命中立刻返回1，遍历完都没命中就返回0。

优化后的脚本示例：

local target_user = ARGV[1]
for _, set_key in ipairs(KEYS) do
    if redis.call('SISMEMBER', set_key, target_user) == 1 then
        return 1
    end
end
return 0

这个版本比你之前的拼接方式效率高不少，Redis处理KEYS数组是原生高效的，没了字符串拆分的额外开销，30个键的场景下延迟应该能明显下降。

什么时候适合分批执行 #

如果你的键数量要涨到50个以上，或者担心单脚本长时间执行阻塞Redis（Lua脚本是原子执行的，跑太久会占住Redis单线程影响其他请求），那分批执行（比如每次传10个键）更稳妥。

客户端逻辑：每次拿10个键调用脚本，返回1就立刻终止后续请求；返回0就继续下一批，直到所有批次查完再返回0。这种方式单次脚本执行时间短，不会阻塞Redis，但会增加少量网络请求，需要根据业务场景权衡延迟和吞吐量。

更彻底的架构级优化 #

如果这类检查特别频繁，键的数量还会持续增长，那可以从架构层面彻底解决问题：

维护全局用户集合 #

搞一个全局集合（比如ALL_PUBSUB_USERS），每次往PUBSUB_USER_SET-*里添加userId时，同步把userId加到这个全局集合；删除userId时，先从子集删除，再检查子集里是否还存在该用户，不存在的话再从全局集合删除。

添加用户的Lua脚本示例：

-- KEYS[1] 是具体的PUBSUB_USER_SET键，KEYS[2]是全局集合ALL_PUBSUB_USERS，ARGV[1]是userId
redis.call('SADD', KEYS[1], ARGV[1])
redis.call('SADD', KEYS[2], ARGV[1])
return 1

删除用户的Lua脚本示例：

redis.call('SREM', KEYS[1], ARGV[1])
-- 确认子集无该用户后，再从全局集合删除
if redis.call('SISMEMBER', KEYS[1], ARGV[1]) == 0 then
    redis.call('SREM', KEYS[2], ARGV[1])
end
return 1

之后检查用户是否存在，只需要一次SISMEMBER ALL_PUBSUB_USERS userId操作，O(1)性能拉满。唯一代价是写入时多了一步操作，但适合读多写少的场景——毕竟读请求的性能提升是量级的。

SCAN遍历（不推荐高频使用） #

如果你的键有统一前缀，也可以用SCAN命令遍历所有符合前缀的键，再逐个检查SISMEMBER。但SCAN是渐进式遍历，可能需要多次请求才能拿到所有键，且遍历过程中键可能新增/删除，适合实时性要求不高、键数量极大的场景，一般不建议用来做高频检查。

总结 #

• 键数量在30-50个以内：**用优化后的单Lua脚本（KEYS数组传键+提前终止）**即可，性能比原方案提升明显。
• 键数量超过50个：分批执行脚本，控制每批10-20个键，命中即停，避免阻塞Redis。
• 读多写少且检查频繁：维护全局用户集合是长期最优方案，彻底解决多次检查的性能问题。

内容的提问来源于stack exchange，提问作者noob