-
是，HLL适合统计日活UV，但需接受约0.81%误差且不支持成员查询与精确交集；按日期分key（如uv:20240520）、设过期、统一用户标识方可稳健使用。
-
AOF重写阻塞主线程的根本原因是fork()系统调用引发的页表复制与copy-on-write冲突；高频key修改导致大量脏页拷贝，使fork耗时飙升。
-
Pub/Sub频道命名必须带租户前缀，采用三段式结构{租户标识}:{业务域}:{实体ID}，禁用裸频道和通配符泛订阅；ACL需按前缀精确控制，显式授权+subscribe/+publish；TLS与消息体加密必须同时启用；Pub/Sub不可替代可靠队列，应改用Stream或List。
-
彻底禁用RDB自动触发需注释或设为save""，重启或CONFIGREWRITE后CONFIGGETsave返回["save",""]，且rdb_changes_since_last_save持续增长即生效。
-
Redis原生SINTER不支持带权重或条件过滤的交集计算，因其仅做纯元素匹配；需用Lua脚本在服务端原子执行复杂逻辑，但须防范阻塞、性能与维护风险。
-
缓存雪崩主因是大量key过期时间高度趋同，需通过扫描TTL、监控expired_keys曲线及检查写入逻辑验证；应采用SETEX或SET...EX原子命令，在基础过期时间上叠加5%–20%随机偏移，并确保所有写入路径（含定时任务、MQ、后台）均覆盖随机化。
-
选择合适的MySQL数据类型能节省存储空间、提升查询性能并确保数据准确性。常见的数据类型分为数值型（如INT、DECIMAL）、字符串型（如CHAR、VARCHAR）和日期时间型（如DATE、DATETIME、TIMESTAMP）。选择时应遵循几个关键点：1.节省存储空间，如状态字段用TINYINT；2.提高查询效率，优先使用定长类型；3.避免精度丢失，金额字段用DECIMAL；4.注意默认行为差异，如TIMESTAMP自动处理时区。常见场景推荐：用户ID用INTUNSIGNED或BIGINT，用户名用V
-
Redis集群中requirepass无效，因其仅作用于客户端端口（如6379），不约束集群总线端口（如16379）；节点间通信明文进行，需依赖网络隔离、ACL及正确配置cluster-announce-ip等措施保障安全。
-
Redisset命令只支持字符串值，存对象需先序列化为JSON；注意处理日期、枚举等特殊字段，避免额外引号，跨语言场景优先选JSON而非Java原生序列化。
-
GEORADIUS返回空结果最常见原因是经纬度顺序写反，必须经度在前、纬度在后；而高德/百度等地图API默认是纬度在前、经度在后，导致坐标存入错误位置。
-
RedisPub/Sub不支持优先级，仅为瞬时广播；真正优先级队列需用List+BRPOP多键轮询，按queue:high→queue:medium→queue:low顺序原子消费，Pub/Sub仅作轻量通知触发器。
-
根本原因是sentineldown-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFOreplication正常但日志频繁出现+sdown又快速恢复。
-
Redis的WATCH+Lua无法实现可靠乐观锁，因WATCH不监控Lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子Lua脚本中完成。
-
MySQL的查询缓存已废弃，是否还值得使用取决于版本和业务场景。1.查询缓存可缓存SELECT语句及其结果，提升读多写少场景的性能；2.但一旦表有写入操作，相关缓存会被清空，高并发写入时易引发性能问题；3.MySQL5.7.20开始标记为废弃，8.0彻底移除，建议使用Redis等外部缓存替代；4.启用时需配置query_cache_type和query_cache_size参数，并合理控制内存大小；5.可通过Qcache_hits、Com_select、Qcache_inserts等状态变量判断缓存命中情
-
RedisCluster默认不支持传统Pub/Sub跨节点广播，因频道按slot分片且gossip协议不传播订阅状态，SUBSCRIBE仅在本地节点生效；根本原因在于集群设计只负责数据分片，不实现消息路由。
