问题索引
是否支持 Lua 脚本功能？
支持。标准架构和集群架构均默认开通 Lua 功能。集群架构下使用 Lua 脚本时，需确保脚本中操作的 Key 在同一 Slot 内，否则可能执行失败。
是否支持缓存失效订阅事件？
支持。分布式缓存数据库支持 Key 过期事件的订阅通知，可通过
PSUBSCRIBE 命令订阅 __keyevent@*__:expired 频道来监听缓存失效事件。什么是大 Key 和热 Key？如何发现和处理？
大 Key
大 Key 是指数据量较大的 Key。不同数据结构的判断标准如下：
数据结构 | 大 Key 阈值 |
String | Value 大小超过10KB |
Hash、List、Set、ZSet | 元素个数超过5,000个 |
大 Key 的主要影响：
内存不均：集群架构下，大 Key 所在节点的内存使用率明显偏高，导致数据倾斜。
请求阻塞：对大 Key 执行
DEL、GETALL 等操作会阻塞 Redis 单线程，导致其他请求超时。同步中断：主从同步时若有大 Key 写入，可能触发同步缓冲区溢出，导致全量同步。
热 Key
热 Key 是指被频繁访问的 Key。判断标准：单个 Key 的 QPS 超过实例总 QPS 的10%，或访问频率远超其他 Key。热 Key 的主要影响：
集群架构下，热 Key 所在的分片 CPU 使用率偏高。
热 Key 出队或过期时可能引发请求阻塞。
如何发现大 Key 和热 Key？
控制台大 Key 分析：在实例详情页的诊断分析中，可一键扫描全量 Key，识别大 Key。
DBbrain 智能诊断：自动发现大 Key 和热 Key，并展示内存占用、访问频率等详细信息。
命令方式：通过
redis-cli --bigkeys 扫描大 Key（注意：此命令会遍历所有 Key，建议在从节点或低峰期执行）。处理方法：
拆分大 Key：将大 String 按业务维度拆分为多个小 Key；将大 Hash 拆分到多个小 Hash。
热 Key 分散：为热 Key 添加业务前缀（如
key_1、key_2、key_3），分散到不同 Slot；在业务层增加本地缓存。及时清理：对已无用的大 Key 及时删除，释放内存。
如何设置缓存淘汰策略？
策略 | 说明 |
volatile-lru | 从设置了过期时间的 Key 中淘汰最近最少使用的 |
allkeys-lru | 从所有 Key 中淘汰最近最少使用的 |
volatile-ttl | 从设置了过期时间的 Key 中淘汰即将过期的 |
noeviction | 不淘汰，内存满时写入失败（默认） |
实例内存满了写入失败怎么办？
当实例内存使用达到上限且淘汰策略为
noeviction（默认）时，所有写入请求将返回 OOM（Out of Memory）错误。处理步骤如下：第一步：确认当前淘汰策略
在控制台查看
maxmemory-policy 参数。若为默认的 noeviction，说明内存满后系统不会主动淘汰 Key，需手动介入。第二步：短期应急：清理无用数据
使用
SCAN 命令遍历并清理已知无用的 Key。若业务允许丢失部分冷数据，可临时将淘汰策略改为
allkeys-lru 或 volatile-lru，让系统自动淘汰最近最少使用的 Key。第三步：长期解决：分析内存占用
通过控制台的大 Key 分析功能，找出内存占用最大的 Key 并优化。
检查是否有大量 Key 未设置过期时间（TTL），对临时性数据补设 TTL。
若数据量确实超出当前规格容量，执行在线扩容操作提升内存上限。
淘汰策略选择建议：
业务场景 | 推荐策略 |
纯缓存场景（数据可丢失） | allkeys-lru |
缓存与持久化混合 | volatile-lru |
数据不可丢失 | noeviction（配合容量告警和扩容） |
为什么设置了过期时间的 Key 没有被及时删除？
Redis 的 Key 过期清理采用"惰性删除 + 定期扫描"双重机制，因此 Key 过期后并不会立即从内存中删除：
惰性删除：Key 过期后只有在下次被访问时才会检查并删除。如果一个 Key 过期后再也没人访问，它会继续占用内存。
定期扫描：Redis 每100ms随机抽取一批设置了过期时间的 Key 进行检查，删除其中已过期的。这意味着过期 Key 的清理存在随机性和延迟。
常见疑问：
Q: 为什么执行
DBSIZE 看到的 Key 数量比预期多？已过期但尚未被惰性删除或定期扫描命中的 Key 仍会被
DBSIZE 统计。这些 Key 会在后续被访问时删除，或在下一轮定期扫描中被清理，不影响业务逻辑（GET 已过期 Key 会返回 nil）。Q: 大量 Key 同时过期（集中过期）会有什么影响？
若大量 Key 设置了相同的过期时间，到期时定期扫描线程需要集中处理大批过期 Key，可能导致 CPU 使用率短时升高，甚至引起请求延迟抖动。建议为过期时间添加随机偏移量：
# 示例：基础 TTL 为 3600 秒，加上 0-300 秒的随机偏移EXPIRE key (3600 + random(0, 300))
Q: 从节点上为什么能看到已过期的 Key？
从节点不会主动删除过期 Key，必须等主节点发送 DEL 指令后才执行删除。因此在从节点执行
DBSIZE 或 SCAN 时可能看到已过期但未被删除的 Key。这是 Redis 主从复制的设计行为，不影响业务读取（Redis 4.0及以上版本的从节点在读取时会检查 TTL 并返回 nil）。高危命令为什么要禁用？如何配置？
高危命令是指可能导致数据丢失或严重影响性能的 Redis 命令。分布式缓存数据库支持在控制台禁用或重命名高危命令，避免因误操作造成线上事故。
常见高危命令及风险
命令 | 风险说明 |
KEYS * | 遍历所有 Key，实例 Key 数量大时会阻塞 Redis 数秒甚至更久 |
FLUSHALL | 清空所有数据库的全部数据，不可恢复 |
FLUSHDB | 清空当前数据库的全部数据，不可恢复 |
CONFIG SET | 动态修改运行配置，可能导致服务异常 |
禁用方法
登录控制台，进入实例详情页的参数配置，找到
disabled-commands 参数，添加需要禁用的命令名称（多个命令用逗号分隔）。配置后，客户端执行被禁用的命令时会收到错误提示。具体操作，请参见 通过 disable-command-list 配置禁用命令。替代方案
用
SCAN 替代 KEYS *，支持游标分批遍历，不会阻塞主线程。需清理数据时，通过备份恢复到新实例后验证，而非直接执行
FLUSHALL。配置变更统一通过控制台的参数配置功能进行，而非
CONFIG SET。账号误删或忘记密码怎么办？
误删账号：登录控制台，进入目标实例的账号管理页面，重新创建账号即可。
忘记密码：在账号管理页面找到对应账号，执行重置密码操作。
注意：
重置密码会导致使用旧密码的连接中断，请在业务低峰期操作并提前通知相关人员。
集群架构的 Hash 算法是怎样的？
集群架构的 Hash 算法与社区 Redis Cluster 一致，采用 CRC16 哈希算法：
HASH_SLOT = CRC16(key) mod 16384
所有 Key 通过此算法均匀分配到16384个哈希槽中，再由各分片负责管理对应的槽位。
标准架构中 select 0 - 15 需要申请不同实例吗？
不需要。标准架构默认支持16个数据库（DB 0 - DB 15），一个实例即可满足多数据库需求。集群架构通过 Proxy 支持最多256个数据库。
Pipeline 是什么？如何使用？
Pipeline（管道）是 Redis 提供的批量执行命令的机制。通过将多个命令打包一次性发送给服务端，减少网络往返次数（RTT），从而提升批量操作的吞吐量。
性能对比
执行方式 | 发送1000条命令耗时（内网1ms RTT） |
逐条执行 | ≈ 1000ms（1000次网络往返） |
Pipeline（每批100条） | ≈ 10ms（10次网络往返） |
使用示例
# Python redis-py 示例import redisr = redis.Redis(host='<实例地址>', port=6379, password='<密码>')# 创建 Pipelinepipe = r.pipeline(transaction=False)# 批量写入for i in range(1000):pipe.set(f'key:{i}', f'value:{i}')# 一次性执行results = pipe.execute()
使用注意事项
1. 控制单次批量大小：建议每个 Pipeline 包含100 - 500条命令。过多命令会导致服务端一次性返回大量数据，可能占用过多内存或触发带宽限制。
2. 非原子性：Pipeline 仅是批量发送，不保证原子性（中间某条命令失败不会回滚其他命令）。如需原子操作请使用事务（MULTI/EXEC）。
3. 集群架构限制：集群架构下，Pipeline 中的命令可由 Proxy 自动路由到不同分片，无需业务侧感知 Slot 分布。但若需要保证命令顺序性，建议同一 Pipeline 中的命令访问同一个 Key。
4. 超时设置：批量命令的整体执行时间可能较长，建议适当调大客户端的读取超时时间。
5. 带宽风险提示：Pipeline 批量返回可能导致出流量瞬时飙高。若实例出现出流量过高告警，建议减小单次 Pipeline 的命令数量，或将批量操作分散到多个时间段执行。
