-
RedisLua脚本原生不支持复杂正则匹配，仅提供基础模式匹配（如%d+），不支持\d、(?i)、.*?、分组捕获等；禁止动态加载外部库（如lrexlib-pcre）；推荐在客户端处理或使用RediSearch的FT.SEARCHREGEX。
-
必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
-
PSUBSCRIBE性能瓶颈源于PUBLISH时线性遍历所有pattern做glob匹配。无索引、无缓存、无短路，pattern越多越慢；大小写敏感且*不匹配空字符串，易误配；超20个pattern或100qps即引发CPU毛刺。
-
直接用DEL释放锁会误删其他客户端的锁，因判断持有锁与删除非原子操作；Lua脚本通过原子执行“GET校验+DEL”解决，需传入key和client_id，返回1成功、0失败。
-
RedisLua脚本不能实现真正的分布式事务回滚，仅能通过条件化原子写入预防性拒绝，失败后需业务层设计补偿机制。
-
必须同时启用io-threads和io-threads-do-reads，否则I/O线程不参与读请求处理；io-threads≥2才生效，需configrewrite或重启；推荐值为min(4,CPU核心数×0.7)，NUMA架构下必须用server_cpulist绑定同node核心。
-
RedisPub/Sub不支持自动消息压缩，因PUBLISH内容直写输出缓冲区，绕过LZF等内存压缩逻辑；需客户端自行压缩/解压，并统一算法；高频短消息推荐LZ4/Snappy；长期应改用Stream替代。
-
命中率低于75%（即keyspace_hits:keyspace_misses<3:1）时应调整淘汰策略，因缓存已无法有效分担数据库压力；需结合evicted_keys增速与keyspace_misses增速同步上升来确认问题根源。
-
redis-cli--clusterinfo仅提供槽位、键数和从节点数的粗粒度分布，无法反映真实CPU/内存负载；需结合INFOmemory、SLOWLOG和INFOstats交叉验证，因slot均匀不等于负载均匀。
-
Redis7.0的io-threads仅加速socketread/write/RESP解析，不执行命令；盲目开启或多设线程数反致延迟上升、吞吐下降，需先确认瓶颈确在IO层而非主线程或内存带宽。
-
Redis集群不支持Pub/Sub跨节点广播，因设计上无全局频道路由机制，PUBLISH消息仅被本地订阅者接收；应改用单节点Redis+连接池，或升级至Kafka/Pulsar等专业消息中间件。
-
repl-backlog-ttl是Redis主节点在无从节点连接时自动释放复制积压缓冲区的时间阈值，默认3600秒；超时后清空backlog，导致重连从节点无法部分同步而触发开销巨大的全量同步。
-
Lettuce管道中flushCommands()仅发送命令不返回结果，正确做法是先保留各操作返回的RedisFuture，再调用get()或thenApply()获取响应。
-
RedisLua脚本无法实现SCAN分页，因脚本无状态且无法维护游标；唯一可行方案是客户端驱动SCAN分页，Lua仅负责单次结果的模式匹配与截取。
-
volatile-lru不适合社交关系链，因其仅淘汰带过期时间的key，而关系数据作为主数据映射不应设TTL；强行加EXPIRE会引发雪崩与CPU升高；allkeys-lfu更匹配二八流量特征，配合调大maxmemory-samples和合理配置LFU衰减可提升淘汰精准度。
