-
MAXLEN是RedisStreams唯一实时限长方式，必须与XADD原子配合使用；~N为近似保留，N为严格上限；XTRIM仅作兜底，非实时；语法中MAXLEN须紧随stream名后，错位即报错。
-
推荐用base64url编码6字节随机数生成短码，冲突概率低且不可预测；需先EXISTS校验再写入，跳转用Lua脚本原子读URL并INCR计数，Redis用String类型存short:{code}→URL，设EX过期，stat:{code}单独存访问量。
-
RedisLua脚本无法实现SCAN分页，因脚本无状态且无法维护游标；唯一可行方案是客户端驱动SCAN分页，Lua仅负责单次结果的模式匹配与截取。
-
首要排查项是repl-timeout，默认60秒，主从间REPLCONFACK延迟超时即断连；需主从同时调大该值，如设为120秒，并排查TCP保活、输出缓冲区、系统连接限制及ACK抖动等隐性瓶颈。
-
客观下线（ODOWN）需多个哨兵通过Gossip协议交换信息并达成quorum共识；quorum是sentinel.conf中配置的最小同意数，非哨兵总数，设为1则退化为主观下线；哨兵间通过SENTINELis-master-down-by-addr命令探测，超时未响应将导致无法凑够quorum；Gossip异步、无中心、带超时，不保证强一致，以换取快速故障发现与低带宽开销；验证ODOWN应使用SENTINELmasters检查flags是否含odown，而非仅依赖+sdown日志。
-
新消费者收不到旧消息是因为XGROUPCREATE默认从最新偏移（$）开始消费，不自动回溯；需显式指定起始ID0或用XREADGROUPSTREAMSmystream0补读，且必须及时XACK避免重复分配。
-
redis-cli的monitor命令可实时打印所有指令但仅限调试环境，因性能开销大、无过滤能力、输出非结构化，生产环境应禁用；推荐用slowlog（设slowlog-log-slower-than为0）替代。
-
MySQL管理数据库连接的核心在于高效配置与优化连接池，以避免资源过度消耗并提升性能。1.连接过多会导致性能下降、资源耗尽、响应延迟和连接拒绝；2.连接池核心参数包括initialSize（初始连接数）、maxActive（最大连接数）、minIdle（最小空闲连接数）和maxWait（最大等待时间），需根据业务量和服务器性能合理设置；3.调优策略包括监控连接使用情况、进行压力测试、逐步调整参数及采用动态调整机制；4.最佳实践涵盖缩短连接占用时间、使用事务、避免耗时操作、使用预编译语句及及时关闭连接；5.
-
缓存击穿是热点key过期瞬间大量请求直击数据库，微服务中因多实例并发回源使DB压力放大N倍；需用原子SET命令加锁、逻辑过期替代永不过期、服务自治布隆过滤器并强同步更新。
-
RedisGEOHASH命令返回标准Base32编码的Geohash字符串数组，长度1-12位，即使单个成员也返回如["wx4g0b0j0r0"]的数组，需取首项；仅对GEOADD添加的成员有效，未添加则返回[nil]。
-
AOF重写加剧SSD寿命损耗，因其每次均全量生成新文件并原子替换，引发高频页擦除与搬移（写放大）；频繁触发（如每小时2–3次）使SSD磨损加速，实测寿命比纯RDB缩短30%+。
-
XDEL对已消费消息无效，因其仅逻辑删除未被任何消费者组读取的消息；已入PEL的消息调用XDEL会静默返回0，必须用XACK释放再XTRIM裁剪。
-
LPUSH+BRPOP不能直接做可靠循环队列，因为BRPOP阻塞等待导致无法自动重入，需外部调度；且List缺乏状态跟踪、幂等支持和消费确认机制，易丢任务或重复消费。
-
SENTINELFAILOVER无反应大概率因哨兵未达成共识或主节点状态不满足切换前提：需至少3个哨兵在线且通信正常，目标master必须存在于SENTINELMASTER列表且角色为master，quorum值不可高于实际哨兵数；命令返回OK不代表切换完成，须依次验证哨兵failover_in_progress标志、新主role:master且无master_host、旧主已变为slave并指向新主；手动触发不模拟真实故障路径，无法检测发现延迟、重连失败及客户端重定向问题；演练前须调大down-afte
-
BITFIELD存储指定宽度和符号性的整数片段（如i8、u16），非完整整数对象；支持位级读写、原子增减及溢出控制，但需注意偏移单位为位、未初始化位返回0、跨字节边界正确处理及客户端解析差异。
