使用配置noeviction策略的云Redis作为持久化数据库是否可行？

• 写入可用性风险：即使你预先评估了内存容量，也可能因为未计入的Redis内存开销（比如键值元数据、客户端缓冲区、主从复制缓冲区、Lua脚本占用内存等）触发内存上限，此时noeviction策略会直接拒绝所有写入请求，直接导致业务写入失败。如果业务存在批量写入、大键突发写入的场景，内存超配的概率会进一步提升，还可能出现单大键写入失败拖累整批操作的问题。
• 持久化可靠性天然不足：Redis本质是内存数据库，默认的持久化配置存在数据丢失窗口：RDB快照是定时生成，故障时会丢失上次快照后的所有写入；AOF即使配置为每秒刷盘，极端情况下也会丢失最多1秒的写入数据。和传统基于磁盘的持久化数据库相比，Redis的持久化可靠性要低一个量级，作为核心持久化存储使用时，数据丢失的风险天然更高。
• 成本投入过高：全量数据都存储在内存中，单位存储成本是磁盘型数据库的数倍到数十倍，当数据量增长到一定规模后，成本会成为非常大的负担，尤其是冷数据占比较高的业务场景，内存资源浪费非常严重。
• 运维复杂度高：你需要持续监控内存使用率、键增长趋势，提前进行容量规划和扩容，一旦扩容不及时就会触发写入拒绝。此外大键、热键、过期键集中回收等问题都会引发内存波动，排查和处理成本远高于传统持久化数据库。

即使你配置了足够大的内存，云服务商侧的基础设施重构、故障切换、补丁更新等操作依然存在key丢失的可能，常见场景如下：

• 故障切换场景：云Memorystore通常采用主从架构，主从数据同步本身存在延迟，当主节点突发故障触发自动切换时，还未同步到从节点的增量写入数据会直接丢失。写入QPS越高、主从同步延迟越大，丢数据的概率和丢失量也越高。
• 补丁更新、基础设施迁移/重构场景：这类操作通常需要重启实例或者进行主从切换，如果操作过程中出现强制断流、持久化文件刷盘异常、跨节点数据同步中断等问题，就可能出现数据不一致甚至部分key丢失的情况。如果云厂商操作前未完整刷取内存数据到持久化磁盘，重启后就会直接丢失未刷盘的写入数据。
• 持久化文件损坏风险：如果运维操作触发的重启刚好发生在RDB快照生成、AOF重写的过程中，可能会导致持久化文件损坏，实例重启时无法完整加载所有key，出现部分甚至全部数据丢失的问题。

内容的提问来源于stack exchange，提问作者Jagrav454