-
Redis集群不支持跨槽位Lua脚本原子执行，所有key必须位于同一slot，可通过哈希标签（如{1001}）强制路由、客户端ASKING模式及KEYS参数传入确保合规。
-
RedisPub/Sub不能替代RabbitMQ，因其不保证消息可达、无持久化订阅、无消费确认机制，消息丢失理直气壮；它纯内存广播，断连、重启后消息全丢，无积压、无offset、无重试，仅适用于允许丢失的实时轻量场景。
-
哨兵判定主节点“客观下线”失败的常见现象是客户端连接断开、写请求超时，但sentinelinfo显示master-status:ok或sentinels数量不足，本质是哨兵未达成quorum票数共识；原因包括quorum设置过大、哨兵间26379端口不通、monitor配置不一致等。
-
会，大量key同时过期会引发CPU尖峰、内存延迟释放和请求抖动；Redis通过每100ms随机抽样检查过期key，超25%过期则连续多轮高强度扫描删除，导致延迟飙升甚至超时。
-
Redis主从心跳由应用层PING和REPLCONFACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。
-
<p>MySQL数据库创建的完整流程包括规划、命名、创建数据库、创建表、权限管理和最佳实践。1.规划时需考虑数据类型、规模、访问频率和扩展性。2.命名应简洁明了并与项目一致，如"projectx_db"。3.使用SQL命令创建数据库并设置字符集和排序规则，如CREATEDATABASEprojectx_dbCHARACTERSETutf8mb4COLLATEutf8mb4_unicode_ci;。4.创建表时遵循规范化设计，避免数据冗余，如CREATETABLEusers(idINTAUTO_
-
Redis不内置BloomFilter，需借助Redisson等第三方实现；EXISTS和空值缓存无法有效防穿透，因前者不拦截非法ID、后者易致缓存污染；布隆过滤器以极小空间开销提供高效存在性否定判断。
-
ShedLock通过Redis的SETkeyvalueEXsecondsNX原子命令实现加锁，键为shedlock:{任务名}，值为节点标识，TTL由lockAtMostFor控制；重复执行主因是Redis配置不一致、集群未适配、绕过AOP或TTL过短。
-
volatile-lru是仅在带TTL的key中按LRU算法驱逐的内存淘汰策略，不处理未设置过期时间的key；会话key必须显式设置TTL，否则成为永生key导致内存溢出。
-
maxclients作用于每个Redis实例（节点）而非整个集群，集群中6个节点需单独配置；其实际生效值取配置值与系统ulimit-n的较小值，且slave节点因承担复制和读请求双重压力更易触顶。
-
磁盘满是配置失当与监控缺位导致的事故信号，表现为RDB写入失败、AOF重写卡住等错误；根本原因是未限maxmemory、AOF重写阈值过松、过期键堆积及数据与日志混放同一分区。
-
内存淘汰不会触发invalidation消息，因其是后台异步驱逐，不走命令执行路径，tracking模块无法感知；只有DEL、SET、EXPIRE等显式变更命令才会触发。
-
AOF重写期间used_memory_rss突然翻倍，根本原因是Redis启用双缓冲机制并触发COW大量页复制。主进程同时维护新旧AOF缓冲区，大Key修改或哈希扩容导致RSS飙升1.5–2倍，OOMkiller可能介入。
-
调大hash-max-ziplist-entries内存不降反升，因ziplist启用需同时满足entries、value长度及数据紧凑三条件；单个value超hash-max-ziplist-value即退化为hashtable。
-
布隆过滤器不支持单元素删除，BF.EXISTS返回true时数据可能已不存在，导致缓存穿透；应改用支持CF.DEL的CuckooFilter或定期重建带时间戳的过滤器。
