副本顶上
复制（replication）会把你的数据集复制一份到副本，与主库实时同步。一旦主库遭遇硬件或整个可用区故障，Redis Cloud 会自动提升副本为新主库、把端点切过去——这就是高可用。
某个节点挂了，服务还在
高可用（High Availability）说白了就一句话：某个节点故障，服务不中断。而实现它的地基，是复制。
当你开启复制，数据集会被复制出一份副本，与主库保持同步。它带来两样东西：自动故障切换 与更强的容错——在硬件故障或整个可用区故障时，防止数据丢失、保持在线。
副驾也捧着同一份路书。主驾突然不行了，副驾立刻接手方向盘，车不停、乘客几乎没察觉。副本就是那位随时待命的副驾。
复制要双份内存。 一份主、一份副本，所以内存上限是数据集大小的 2 倍。规划容量时别忘了这一点。
无副本 · 单区 · 多区
Redis Cloud 提供三个复制级别，抗故障能力依次增强。
区域方案只能在创建订阅时定。 多区 ↔ 单区之后不能互转。要换，只能新建一个订阅、再迁移数据过去。
幕后的四步
实时同步
主库把写操作持续复制给副本，两边数据保持一致。
检测故障
系统发现主库不再健康（无响应 / 节点或可用区故障）。
提升副本
把数据最新的副本提升为新的主库，让它开始接收读写。
端点重定向
连接端点自动指向新主库，应用重连后照常工作。
正因为会发生切换，应用要按「可自动重连」的最佳实践来写——切换发生时能优雅地重连到新主库，把中断降到最低。
复制 ≠ 持久化 ≠ 备份
这三件事常被混为一谈，其实各管一段风险。想真正稳，最好三者都要。
复制 → 可用性
某个节点没了，另一个立刻顶上，服务不中断。防的是「宕机」。
持久化 → 持久性
整个库重启 / 断电后，能从磁盘把数据读回来（见上一篇 AOF）。防的是「重启丢数据」。
备份 → 灾难恢复
误删 / 逻辑损坏时，能回滚到某个历史时间点。防的是「手滑删库」。
一句话：扛节点故障靠复制，扛重启断电靠持久化，扛误删错改靠备份。副本再多，也替代不了备份。
什么时候能改，有讲究
创建时选区域方案
付费 Essentials 与 Pro 都可在创建订阅时选择多区或单区（也可以不开复制）。可用区（Zone）设置一旦订阅激活就锁死。
之后能改的范围
算好内存（2 倍）
复制需要双倍内存。Essentials 的计划尺寸已含副本，所以可用数据量是计划的一半：
Pro 则是你先选数据集大小，系统再按复制设置算出内存上限。复制也会随流量上升带来同步开销。
省钱小贴士：让集群和应用尽量放在同一可用区，可降低网络传输费和延迟；若开启 Multi-AZ，需选择 3 个可用区。免费 Essentials 不支持复制。
关于高可用的几个真相
节点没了，服务不停
复制把数据变成「一主一副」，主库倒下、副本秒顶。要真正的高可用，用多区副本，再叠上持久化和备份——把宕机、断电、误删这三种坑一次堵上。
