问题索引
分布式缓存数据库支持数据持久化吗？
Redis 引擎和 Valkey 引擎均支持数据持久化，系统默认开启 RDB + AOF 混合持久化策略：
RDB（Redis Database Backup）：定期将内存数据生成快照写入磁盘，占用空间小，恢复速度快。
AOF（Append Only File）：记录每条写命令，数据安全性更高。系统默认每秒刷盘一次（
appendfsync everysec），在性能与数据安全之间取得平衡。此外，分布式缓存数据库还提供自动备份和手动备份能力。系统每天自动执行一次全量备份，备份数据默认保留7天（可配置为1 - 30天）。用户也可随时在控制台手动触发备份，用于变更前的数据保护。
说明：
Memcached 引擎为纯内存缓存，不支持数据持久化。
刚购买的实例存储容量就占用了2M，是正常的吗？
正常。这是系统维持自身数据结构所用的空间，属于正常现象，不影响业务使用。
实例支持的最大连接数是多少？
实例的最大连接数取决于架构类型和实例规格：
架构类型 | 最大连接数 |
标准架构 | 10,000 - 40,000（随规格递增） |
集群架构 | 10,000 × 分片数 |
当连接数接近上限时，可通过以下方式优化：
检查客户端是否使用连接池，避免频繁创建和销毁连接。
排查是否存在连接泄漏（长时间空闲的连接未释放）。
若业务确实需要更多连接，可通过升级实例规格或增加分片数来提升连接数上限。
如何处理实例内存使用率过高的问题？
当实例内存使用率持续超过80%时，建议采取以下措施：
排查大 Key
登录控制台，使用大 Key 分析功能扫描实例中的大 Key。大 Key 不仅占用大量内存，还可能导致请求延迟升高和主从同步中断。建议将超过10MB的 Key 拆分为多个小 Key，或使用 Hash 结构替代单个大 String。
检查过期策略
确认业务数据是否设置了合理的过期时间（TTL）。若存在大量未设置 TTL 的 Key，内存将持续增长。可通过
OBJECT IDLETIME 命令检查 Key 的空闲时间，对长期未访问的数据设置过期策略或手动清理。扩容实例
若优化后内存使用率仍然偏高，说明当前规格已无法满足业务需求。可在控制台进行在线扩容——标准架构支持纵向扩容（提升内存规格），集群架构支持横向扩容（增加分片数）。扩容过程通常在分钟级完成，期间实例仍可正常读写。
扩容和缩容会中断业务吗？
扩缩容对业务的影响取决于操作类型：
操作类型 | 是否中断 | 说明 |
垂直扩容（扩大内存） | 可能有秒级闪断 | 若超出单机剩余容量，会进行节点迁移，存在秒级闪断；未超出则无影响 |
垂直缩容（缩小内存） | 不中断 | 不会出现秒级闪断 |
水平扩容（增加分片） | 有秒级闪断 | 增加节点会触发数据迁移 |
水平缩容（减少分片） | 有秒级闪断 | 回收节点会触发数据迁移 |
建议在业务低峰期或维护时间窗内执行扩缩容操作，以降低对业务的影响。
实例支持版本升级吗？
支持。分布式缓存数据库支持大版本和小版本两种升级方式：
大版本升级：支持跨版本升级（如从 Redis 5.0 升级到 Redis 6.2 或 7.0），升级后可使用新版本的特性和命令。升级过程中会有短暂的连接闪断（通常秒级），建议在维护时间窗内执行。
小版本升级：系统定期发布小版本更新，包含性能优化和安全修复。支持手动触发或设置为维护时间窗内自动更新。
Proxy 版本升级：引擎版本和 Proxy 版本支持独立升级，互不影响。
说明：
版本升级为不可逆操作，升级前请确保业务代码兼容目标版本。建议先在测试环境验证，再在生产环境执行升级。
实例支持从标准架构升级到集群架构吗？
支持。您可以在控制台实例详情页进行架构升级，将标准架构实例升级为集群架构。升级过程中会有短暂的连接闪断，建议在维护时间窗内执行。
为什么可用内存比购买的规格小？
这是因为系统会预留部分内存用于主从同步和内部管理操作，确保实例的稳定运行。
预留内存的用途：
主从复制缓冲区：主节点向从节点同步数据时需要使用缓冲区（replication backlog），默认占用一定内存。
系统进程开销：Redis 进程本身运行需要消耗少量内存。
Copy-On-Write 预留：执行 RDB 备份或 AOF 重写时，fork 子进程可能产生内存翻倍（Copy-On-Write），预留空间避免 OOM 被系统杀死。
输出缓冲区：客户端和主从同步的输出缓冲区需要占用额外内存。
各规格的实际可用内存：
实际可用内存 = 购买规格内存 - 系统预留内存。系统预留内存通常为规格总量的15% - 20%。例如，购买4GB规格的实例，实际可写入的数据量约为3.2GB - 3.4GB。
建议：
容量规划时按实际可用内存估算，留出20%余量。
设置内存使用率告警阈值为65% - 75%，提前触发扩容评估。
若频繁接近内存上限，建议升级规格而非依赖淘汰策略。
