关于java:面试官Redis如何保证高可用

Redis 高可用（High Availability，HA）是指 Redis 通过一系列技术手段确保在面临故障的状况下也能继续提供服务的能力。

Redis 作为一个内存数据库，其数据通常存储在内存中，一旦产生故障，可能导致数据失落或服务中断，所以，为了保障 Redis 的高可用，它次要采纳了以下两种伎俩：

1. 长久化：长久化机制可能在肯定水平上保障即便在服务器意外进行后，数据还能被复原。
2. 多机部署：将本来为单机的 Redis 服务，变为多个 Redis 节点，主节点用来解决数据的写操作，而后再把最新的数据同步给从节点，这样即便其中有一个节点宕机了，那么其余节点仍然保留了最新的数据，从而防止了 Redis 的单机故障。

但长久化和多机部署又有很多种实现形式，接下来一起来看。

1. 长久化

长久化是指将数据从内存中存储到长久化存储介质中（如硬盘）的过程，以便在程序重启或者零碎解体等状况下，可能从长久化存储介质中复原数据。
Redis 4.0 之后反对以下 3 种长久化计划：

1. RDB（Redis DataBase）长久化：快照形式长久化，将某一个时刻的内存数据，以二进制的形式写入磁盘；
2. AOF（Append Only File）长久化：文件追加长久化，记录所有非查问操作命令，并以文本的模式追加到文件中；

3. 混合长久化：RDB + AOF 混合形式的长久化，Redis 4.0 之后新增的形式，混合长久化是联合了 RDB 和 AOF 的长处，在写入的时候，先把以后的数据以 RDB 的模式写入文件的结尾，再将后续的操作命令以 AOF 的格局存入文件，这样既能保障 Redis 重启时的速度，又能减低数据失落的危险。

   1.1 RDB 长久化

   RDB（Redis Database）是将某一个时刻的内存快照（Snapshot），以二进制的形式写入磁盘的长久化机制。
   RDB 长久化机制有以下优缺点：
   长处：

4. 速度快：绝对于 AOF 长久化形式，RDB 长久化速度更快，因为它只须要在指定的工夫距离内将数据从内存中写入到磁盘上。
5. 空间占用小：RDB 长久化会将数据保留在一个压缩的二进制文件中，因而绝对于 AOF 长久化形式，它占用的磁盘空间更小。
6. 复原速度快：因为 RDB 文件是一个残缺的数据库快照，所以在 Redis 重启后，能够十分疾速地将数据恢复到内存中。
7. 可靠性高：RDB 长久化形式能够保证数据的可靠性，因为数据会在指定工夫距离内主动写入磁盘，即便 Redis 过程解体或者服务器断电，也能够通过加载最近的一次快照文件复原数据。

毛病：

1. 数据可能会失落：RDB 长久化形式只能保证数据在指定工夫距离内写入磁盘，因而如果 Redis 过程解体或者服务器断电，从最初一次快照保留到解体的工夫点之间的数据可能会失落。
2. 实时性差：因为 RDB 长久化是定期执行的，因而从最初一次快照保留到以后工夫点之间的数据可能会失落。如果须要更高的实时性，能够应用 AOF 长久化形式。

所以，RDB 长久化形式适宜用于对数据可靠性要求较高，但对实时性要求不高的场景，如 Redis 中的备份和数据恢复等。

1.2 AOF 长久化

AOF（Append Only File）它是将 Redis 每个非查问操作命令都追加记录到文件（appendonly.aof）中的长久化机制。
AOF 长久化机制有以下优缺点：
长处：

1. 数据不容易失落：AOF 长久化形式会将 Redis 执行的每一个写命令记录到一个文件中，因而即便 Redis 过程解体或者服务器断电，也能够通过重放 AOF 文件中的命令来复原数据。
2. 实时性好：因为 AOF 长久化形式是将每一个写命令记录到文件中，因而它的实时性比 RDB 长久化形式更好。
3. 数据可读性强：AOF 长久化文件是一个纯文本文件，能够被人类读取和了解，因而能够不便地进行数据备份和复原操作。

毛病：

1. 写入性能略低：因为 AOF 长久化形式须要将每一个写命令记录到文件中，因而绝对于 RDB 长久化形式，它的写入性能略低。
2. 占用磁盘空间大：因为 AOF 长久化形式须要记录每一个写命令，因而绝对于 RDB 长久化形式，它占用的磁盘空间更大。
3. AOF 文件可能会呈现损坏：因为 AOF 文件是一直地追加写入的，因而如果文件损坏，可能会导致数据无奈复原。

所以，AOF 长久化形式适宜用于对数据实时性要求较高，但对数据大小和写入性能要求绝对较低的场景，如须要对数据进行实时备份的利用场景。

1.3 混合长久化

Redis 混合长久化是指将 RDB 长久化形式和 AOF 长久化形式联合起来应用，以充分发挥它们的劣势，同时防止它们的毛病，它的优缺点如下：
长处 ：混合长久化联合了 RDB 和 AOF 长久化的长处，结尾为 RDB 的格局，使得 Redis 能够更快的启动，同时联合 AOF 的长处，有减低了大量数据失落的危险。
毛病：

1. 实现复杂度高：混合长久化须要同时保护 RDB 文件和 AOF 文件，因而实现复杂度绝对于独自应用 RDB 或 AOF 长久化形式要高。
2. 可读性差：AOF 文件中增加了 RDB 格局的内容，使得 AOF 文件的可读性变得很差；
3. 兼容性差：如果开启混合长久化，那么此混合长久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

所以，Redis 混合长久化形式适宜用于，须要兼顾启动速度和减低数据失落的场景。但须要留神的是，混合长久化的实现复杂度较高、可读性差，只能用于 Redis 4.0 以上版本，因而在抉择时须要依据理论状况进行衡量。

2. 多机部署

Redis 多机部署次要蕴含以下 3 种形式：

1. 主从同步
2. 哨兵模式

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、设计模式、音讯队列等模块。