Redis 高可用（High AvAIlability，HA）是指 Redis 通过一系列技术手段确保在面临故障的情况下也能持续提供服务的能力。
Redis 作为一个内存数据库，其数据通常存储在内存中，一旦发生故障，可能导致数据丢失或服务中断，所以，为了保证 Redis 的高可用，它主要采用了以下两种手段：
- 持久化：持久化机制能够在一定程度上保证即使在服务器意外停止后，数据还能被恢复。
- 多机部署：将原本为单机的 Redis 服务，变为多个 Redis 节点，主节点用来处理数据的写操作，然后再把最新的数据同步给从节点，这样即使其中有一个节点宕机了，那么其他节点依然保存了最新的数据，从而避免了 Redis 的单机故障。
但持久化和多机部署又有很多种实现方式，接下来一起来看。
1.持久化
持久化是指将数据从内存中存储到持久化存储介质中（如硬盘）的过程，以便在程序重启或者系统崩溃等情况下，能够从持久化存储介质中恢复数据。
Redis 4.0 之后支持以下 3 种持久化方案：
- RDB（Redis DataBase）持久化：快照方式持久化，将某一个时刻的内存数据，以二进制的方式写入磁盘；
- AOF（Append Only File）持久化：文件追加持久化，记录所有非查询操作命令，并以文本的形式追加到文件中；
- 混合持久化：RDB + AOF 混合方式的持久化，Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险。
1.1 RDB 持久化
RDB（Redis Database）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的持久化机制。
RDB 持久化机制有以下优缺点：
优点：
- 速度快：相对于 AOF 持久化方式，RDB 持久化速度更快，因为它只需要在指定的时间间隔内将数据从内存中写入到磁盘上。
- 空间占用小：RDB 持久化会将数据保存在一个压缩的二进制文件中，因此相对于 AOF 持久化方式，它占用的磁盘空间更小。
- 恢复速度快：因为 RDB 文件是一个完整的数据库快照，所以在 Redis 重启后，可以非常快速地将数据恢复到内存中。
- 可靠性高：RDB 持久化方式可以保证数据的可靠性，因为数据会在指定时间间隔内自动写入磁盘，即使 Redis 进程崩溃或者服务器断电，也可以通过加载最近的一次快照文件恢复数据。
缺点：
- 数据可能会丢失：RDB 持久化方式只能保证数据在指定时间间隔内写入磁盘，因此如果 Redis 进程崩溃或者服务器断电，从最后一次快照保存到崩溃的时间点之间的数据可能会丢失。
- 实时性差：因为 RDB 持久化是定期执行的，因此从最后一次快照保存到当前时间点之间的数据可能会丢失。如果需要更高的实时性，可以使用 AOF 持久化方式。
所以，RDB 持久化方式适合用于对数据可靠性要求较高，但对实时性要求不高的场景，如 Redis 中的备份和数据恢复等。
1.2 AOF 持久化
AOF（Append Only File）它是将 Redis 每个非查询操作命令都追加记录到文件（appendonly.aof）中的持久化机制。
AOF 持久化机制有以下优缺点：
优点：
- 数据不容易丢失：AOF 持久化方式会将 Redis 执行的每一个写命令记录到一个文件中，因此即使 Redis 进程崩溃或者服务器断电，也可以通过重放 AOF 文件中的命令来恢复数据。
- 实时性好：由于 AOF 持久化方式是将每一个写命令记录到文件中，因此它的实时性比 RDB 持久化方式更好。
- 数据可读性强：AOF 持久化文件是一个纯文本文件，可以被人类读取和理解，因此可以方便地进行数据备份和恢复操作。
缺点：
- 写入性能略低：由于 AOF 持久化方式需要将每一个写命令记录到文件中，因此相对于 RDB 持久化方式，它的写入性能略低。
- 占用磁盘空间大：由于 AOF 持久化方式需要记录每一个写命令，因此相对于 RDB 持久化方式，它占用的磁盘空间更大。
- AOF 文件可能会出现损坏：由于 AOF 文件是不断地追加写入的，因此如果文件损坏，可能会导致数据无法恢复。
所以，AOF 持久化方式适合用于对数据实时性要求较高，但对数据大小和写入性能要求相对较低的场景，如需要对数据进行实时备份的应用场景。
1.3 混合持久化
Redis 混合持久化是指将 RDB 持久化方式和 AOF 持久化方式结合起来使用，以充分发挥它们的优势，同时避免它们的缺点，它的优缺点如下：
优点：混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。
缺点：
- 实现复杂度高：混合持久化需要同时维护 RDB 文件和 AOF 文件，因此实现复杂度相对于单独使用 RDB 或 AOF 持久化方式要高。
- 可读性差：AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
- 兼容性差：如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。
所以，Redis 混合持久化方式适合用于，需要兼顾启动速度和减低数据丢失的场景。但需要注意的是，混合持久化的实现复杂度较高、可读性差，只能用于 Redis 4.0 以上版本，因此在选择时需要根据实际情况进行权衡。
2.多机部署
Redis 多机部署主要包含以下 3 种方式：
- 主从同步
- 哨兵模式
- Redis Cluster（Redis 集群）
2.1 主从同步
主从同步 (主从复制) 是 Redis 高可用服务的基石，也是多机运行中最基础的一个。我们把主要存储数据的节点叫做主节点 (master)，把其他通过复制主节点数据的副本节点叫做从节点 (slave)，如下图所示：
在 Redis 中一个主节点可以拥有多个从节点，一个从节点也可以是其他服务器的主节点，如下图所示：
2.2 哨兵模式
主从同步存在一个致命的问题，当主节点奔溃之后，需要人工干预才能恢复 Redis 的正常使用。
所以我们需要一个自动的工具——Redis Sentinel (哨兵模式) 来把手动的过程变成自动的，让 Redis 拥有自动容灾恢复 (failover) 的能力。
哨兵模式如下所示：
小贴士：Redis Sentinel 的最小分配单位是一主一从。
2.3 Redis Cluster
Redis Cluster 是 Redis 3.0 版本推出的 Redis 集群方案，它将数据分布在不同的服务区上，以此来降低系统对单主节点的依赖，并且可以大大的提高 Redis 服务的读写性能。
Redis Cluster 架构图如下所示：
从上图可以看出 Redis 的主从同步只能有一个主节点，而 Redis Cluster 可以拥有无数个主从节点，因此 Redis Cluster 拥有更强大的平行扩展能力，也就是说当 Redis Cluster 拥有两个主从节点时，从理论上来讲 Redis 的性能相比于主从来说性能提升了两倍，并且 Redis Cluster 也有自动容灾恢复的机制。
课后思考
Redis 有了持久化机制之后数据一定不会丢失吗？Redis 持久化策略有哪些？
本文已收录到我的面试小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。
