想要彻底搞懂大厂是如何实现Redis高可用的？看这篇文章就够了

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。

那么如何保证系统的高可用呢

首先，在整个架构的每个节点中，不允许存在单点问题，因为单点一定是高可用最大的风险点，我们应该在系统设计过程中去避免单点问题。

在实现方法上，一般采用的就是集群部署、或者冗余部署来实现。这样的设计使得如果某个节点出现故障，其他的节点还可以继续使用。

Redis中高可用设计的必要性

Redis作为一个高性能Nosq中间件，会有很多热点数据存放在Redis中，一旦Redis-server出现故障，会导致所有相关业务访问都出现问题。另外，即便是设计了数据库兜底的方案，大量请求对数据库的访问也很容易导致数据库出现瓶颈，造成更大的灾难。

除此之外，Redis的集群部署还可以带来额外的收益：

• 负载（性能），Redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis服务来完成工作
• 扩容（水平扩展），第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法

在Redis中，提供了高可用方案包含以下几种：

• 主从复制（用来实现读写分离）
• 哨兵机制（实现master选举）
• 集群机制（实现数据的分片）

Redis的Master-Slave方法

主从复制模式，简单来说就是把一台Redis服务器的数据，复制到其他Redis服务器中。其中负责复制数据的来源称为master，被动接收数据并同步的节点称为slave，数据的复制是单向的，如图5-1所示，对于主从模式，其实有很多的变体。

在很多组件中都有使用这种思想，比如mysql的主从复制、redis的主从复制、activemq的主从复制、kafka里面的数据副本机制等等，所以大家需要举一反三，融会贯通。

图5-1

主从复制的好处

1. 数据冗余，主从复制实现了数据的热备，是除了持久化机制之外的另外一种数据冗余方式。
2. 读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
3. 负载均衡，在主从复制的基础上，配合读写分离机制，可以由主节点提供写服务，从节点提供服务。在读多写少的场景中，可以增加从节点来分担redis-server读操作的负载能力，从而大大提高redis-server的并发量
4. 保证高可用，作为后备数据库，如果主节点出现故障后，可以切换到从节点继续工作，保证redis-server的高可用。

Redis如何配置主从复制

需要注意，Redis的主从复制，是直接在从节点发起就行，主节点不需要做任何事情

在Redis中有三种方式来开启主从复制。

• 在从服务器的redis.conf配置文件中加入下面这个配置replicaof <masterip> <masterport>
• 通过启动命令来配置，也就是启动slave节点时执行如下命令

  ./redis-server ../redis.conf --replicaof <masterip> <masterport>

• 启动redis-server之后，直接在客户端窗口执行下面命令redis>replicaof <masterip> <masterport>

准备三台虚拟机

准备好三台虚拟机，并且这三台虚拟机需要能相互ping通，以及相互能够访问6379这个端口，如果访问不了，需要关闭防火墙。

firewall-cmd --zone=public --add-port=6379/tcp --permanent

• 192.168.221.128（master）
• 192.168.221.129（slave）
• 192.168.221.130（slave）

这三台机器上都需要安装redis-server，安装步骤如下。

注意事项，Redis6安装需要gcc版本大于5.3以上，否则安装会报错。

# 升级到gcc 9.3：
yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
scl enable devtoolset-9 bash
# 需要注意的是scl命令启用只是临时的，退出shell或重启就会恢复原系统gcc版本。
# 如果要长期使用gcc 9.3的话：
echo -e "\nsource /opt/rh/devtoolset-9/enable" >>/etc/profile

开始安装

cd /usr/local/
wget http://download.redis.io/releases/redis-6.0.9.tar.gz
tar -zxvf redis-6.0.9.tar.gz
cd redis-6.0.9
make
make test
make install PREFIX=/data/program/redis 
cp redis.conf /data/program/redis/redis.conf

演示配置过程

在192.168.221.129和192.168.221.130这两台机器上分别按照下面的操作增加配置。

• 编辑redis.conf文件，通过shift+g跳转到最后一行，增加如下配置replicaof 192.168.221.128 6379
• 分别启动这两台机器，启动成功后，使用如下命令查看集群状态redis> info replication
• 启动日志中可以看到，在启动过程中已经从master节点复制了信息。

  66267:S 12 Jul 2021 22:21:46.013 * Loading RDB produced by version 6.0.9
  66267:S 12 Jul 2021 22:21:46.013 * RDB age 50 seconds
  66267:S 12 Jul 2021 22:21:46.013 * RDB memory usage when created 0.77 Mb
  66267:S 12 Jul 2021 22:21:46.013 * DB loaded from disk: 0.000 seconds
  66267:S 12 Jul 2021 22:21:46.013 * Ready to accept connections
  66267:S 12 Jul 2021 22:21:46.013 * Connecting to MASTER 192.168.221.128:6379
  66267:S 12 Jul 2021 22:21:46.014 * MASTER <-> REPLICA sync started
  66267:S 12 Jul 2021 22:21:46.015 * Non blocking connect for SYNC fired the event.
  66267:S 12 Jul 2021 22:21:46.016 * Master replied to PING, replication can continue...
  66267:S 12 Jul 2021 22:21:46.017 * Partial resynchronization not possible (no cached master)
  66267:S 12 Jul 2021 22:21:46.039 * Full resync from master: acb74093b4c9d6fb527d3c713a44820ff0564508:0
  66267:S 12 Jul 2021 22:21:46.058 * MASTER <-> REPLICA sync: receiving 188 bytes from master to disk
  66267:S 12 Jul 2021 22:21:46.058 * MASTER <-> REPLICA sync: Flushing old data
  66267:S 12 Jul 2021 22:21:46.058 * MASTER <-> REPLICA sync: Loading DB in memory
  66267:S 12 Jul 2021 22:21:46.060 * Loading RDB produced by version 6.2.4
  66267:S 12 Jul 2021 22:21:46.060 * RDB age 0 seconds
  66267:S 12 Jul 2021 22:21:46.060 * RDB memory usage when created 1.83 Mb
  66267:S 12 Jul 2021 22:21:46.060 * MASTER <-> REPLICA sync: Finished with success

如果没有开启日志，可以通过下面的方法进行开启

找到Redis的配置文件 redis.conf打开该配置文件， vi redis.conf;通过linux的查询命令找到 (loglevel下面)logfile " " ;在冒号里面输入日志的路径，比如logfile “
/usr/local/redis/log/redis.log”， 需要提前创建好目录和文件，redis默认不会创建该文件。

接着，我们在master节点上通过设置一些key，会发现数据立刻就同步到了两个slave节点上，从而完成了主从同步功能。不过在默认情况下，slave服务器是只读的，如果直接在slave服务器上做修改，会报错. 不过可以在slave服务器的redis.conf中找到一个属性，允许slave服务器可以写，但是不建议这么做。因为slave服务器上的更改不能往master上同步，会造成数据不同步的问题

slave-read-only no 

Redis主从复制的原理分析

Redis的主从复制分两种，一种是全量复制，另一种是增量复制。

全量复制

如图5-2所示，表示Redis主从全量复制的整体时序图，全量复制一般发生在Slave节点初始化阶段，这个时候需要把master上所有数据都复制一份，具体步骤是：

• 从服务器连接主服务器，发送SYNC命令；
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令（表示RDB异步生成快照期间的数据变更）；
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

图5-2

问题：生成RDB期间，master接收到的命令怎么处理？

开始生成RDB文件时，master会把所有新的写命令缓存在内存中。在 slave node 保存了RDB之后，再将新的写命令复制给 slave node。（跟AOF重写期间的思路是一样的）

完成上面几个步骤后就完成了slave服务器数据初始化的所有操作，savle服务器此时可以接收来自用户的读请求，同时，主从节点进入到命令传播阶段，在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。