提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

前言

一、Redis主从复制

1.1 概念

1.2 作用

1.3 缺点

1.4 流程

1.5 搭建

1.6 验证

二、Reids哨兵模式

2.1 概念

2.2 作用

2.3 缺点

2.4 结构

2.5 搭建

2.6 验证

三、Redis集群

3.1 概述

3.2 原理

3.3 架构细节

3.4 选举过程

3.4 搭建

3.4.1 基础搭建

3.4.2 构建集群

前言

Redis集群是Redis数据库的一个分布式解决方案，它允许将数据分布在多个Redis节点上以提高性能和可靠性。

Redis集群使用分片的方式将数据分布在多个节点上。每个节点负责存储和处理一部分数据。当进行数据读写操作时，客户端会根据数据的哈希值找到对应的节点，并将操作发送给该节点进行处理。

Redis集群还提供了自动的故障转移和数据迁移功能。当一个节点出现故障时，集群会自动将该节点上的数据迁移到其他正常节点上，以保证数据的可用性。同时，集群还会自动选举新的主节点来接管失效节点的工作。要使用Redis集群，需要至少3个Redis节点。每个节点都是一个独立的Redis服务器实例，并且需要通过配置文件指定集群模式和节点的IP地址和端口号。

Redis集群可以提供高可用性和性能扩展的解决方案，但也需要注意一些限制和注意事项，如无法支持事务、主节点数不能超过16384个等。

提示：以下是本篇文章正文内容，下面案例可供参考

一、Redis主从复制

1.1 概念

Redis主从复制是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。

1.2 作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

1.3 缺点

故障恢复无法自动化；
写操作无法负载均衡；
存储能力受到单机的限制。

1.4 流程

第一步：若启动一个Slave机器进程，则它会向Master机器发送一个“sync command”命令，请求同步连接。
   第二步：无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。
   第三步：后台进程完成缓存操作之后，Maste机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。
   第四步：Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

1.5 搭建

主服务器：（IP：192.168.10.130）
       修改配置文件
           bind 0.0.0.0
           port 6379
           protected-mode = no
           daemonize = yes

   从服务器：
       修改配置文件
           bind 0.0.0.0
           port 6380
           protected-mode = no
           daemonize = yes
           slaveof 192.168.10.130 6379

1.6 验证

使用redis-cli命令行登录redis服务器，输入role指令查看状态
在master节点上，录入数据，在slave节点上查看到对应数据即可

主服务器

在从服务登录查看

二、Reids哨兵模式

2.1 概念

Reids哨兵模式是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master 并将所有 Slave 连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
依托于主从模式

2.2 作用

   监控：哨兵会不断地检查主节点和从节点是否运作正常。
   自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
   通知（提醒）：哨兵可以将故障转移的结果发送给客户端。

2.3 缺点

   写操作无法负载均衡
   存储能力受到单机的限制
   哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

2.4 结构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

2.5 搭建

关闭保护模式
protected-mode no
Redis哨兵默认的监听端口
port 26379

指定日志存放路径
logfile "/var/log/sentinel.log"
指定数据库存放路径
dir "/var/lib/redis"
修改指定该哨兵节点监控192.168.163.10:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.163.10 6379 2
判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel down-after-milliseconds mymaster 30000
故障节点的最大超时时间为180000（180秒）
sentinel failover-timeout mymaster 180000

   bind 0.0.0.0
   port 26379
   daemonize yes
   sentinel monitor mymaster 192.168.115.160 6379 2
   启动
       redis-sentinel 配置文件路径

bind 0.0.0.0
   port 26379 26380 26381
   daemonize yes
   sentinel monitor mymaster 192.168.10.130 6379 2

2.6 验证

可以查看日志文件（/var/log/redis/sentinel.log）

停止master后，slave会通过选举产生新的master
哨兵配置文件会自动修改监听的master节点地址为新的master节点地址

以前停掉的master重新启动不会更改当前哨兵模式选出的master

三、Redis集群

3.1 概述

Redis3.0版本以上开始支持cluster，采用的是hashslot（hash槽），可以将多个Redis实例整合在一起，形成一个群集，也就是将数据分散到群集的多台机器上。

3.2 原理

Redis Cluster是一个无中心的结构，每个节点都保存数据和整个群集的状态。每个节点都会保存其他节点的信息，知道其他节点所负责的槽，并且会与其他节点定时发送心跳信息，能够及时感知群集中异常的节点。

（直接执行这个命令；如果键所在的槽并没有指派给当前节点，那么节点会向客户端返回一个MOVED错误，指引客户端转向（redirect）正确的节点，并再次发送之前想要执行的命令.
群集角色有Master和Slave.Master之间分配slots，一共16384个slot，Slave向它指定的Master 同步数据，实现备份。当其中的一个Master无法提供服务时，该Master的Slave将提升为Mester，以保证群集间 slot 的完整性，当其中的某一个Master和它的Slave都失效，导致了slot不完整，群集失效，这时就需要人工去处理了。
群集搭建好后，群集中的每个节点都会定期地向其他节点发送PING消息，如果接收PONG消息的节点没有在规定的时间内返回PONG 消息，那么发送PNG消息的节点就会将其标记为疑似下线（probable fail，PFAL）。各个节点会通过互相发送消息的方式来交换群集中各个节点的状态信息。如果在一个群集里面，半数以上的主节点都将某个主节点×报告为疑似下线，那么这个主节点×将被标记为已下线（FAL），同时会向群集广播一条关于主节点×的FAL消息，所有收到这条FAL消息的节点都会立即将主节点×标记为已下线。
当需要减少或者增加群集中的机器时，我们需要将已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且将相关槽所属的键值对从源节点移动到目标节点。
Redis群集的重新分片操作是由Redis的群集管理软件redis—trib负责执行的，不支持自动的分片，而且需要自己计算从哪些节点上迁移多少 Slot。在重新分片的过程中，群集不需要下线，并且源节点和目标节点都可以继续处理命令请求。）

3.3 架构细节

   （1）所有的redis节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输速度和带宽。
   （2）节点的失效（fail）在群集中超过半数的主（master）节点检测失效时才生效。
   （3）客户端与 redis 节点直连，不需要中间代理（proxy）层，客户端不需要连接群集所有节点，连接群集中任何一个可用节点即可。
   （4）redis-cluster 把所有的物理节点映射到【0-16383】slot 上，cluster 负责维护 node<->slot<->key。

3.4 选举过程

   选举过程是群集中所有master参与，如果半数以上master节点与当前 master 节点通信超时（cluster—node—timeout），认为当前 master 节点挂掉。以下两种情况为整个群集不可用（cluster_state：fail），当群集不可用时，所有对群集的操作都不可用，收到(（error）CLUSTEFDOWN The cluster is down）错误。
   如果群集任意 master挂掉，且当前 master 没有 slave，则群集进入 fail状态，也可以理解成群集的slot映射【0 ~16383】不完整时进入fail状态。
   如果群集中超过半数的master挂掉，无论是否有slave，群集都进入 fail状态。
   默认情况下，每个群集的节点都使用两个TCP端口.一个是6379，一个是16379；6379服务于客户端的连接，16379 用于群集总线，即使用二进制协议的节点到节点通信通道。节点使用群集总线进行故障检测、配置更新、故障转移授权等。如果开启了防火墙，需要开放这两个端口。

3.4 搭建

3.4.1 基础搭建

准备3台虚拟机，分别设置IP为 192.168.156.3 192.168.156.4 192.168.156.5

1. 安装epel-release源（三台都装）

安装 redis

yum install -y epel-release

yum install -y redis

2.关闭防火墙、修改宽容模式

3. 创建目录、配置文件

4. 进入配置文件，修改配置项（两个）

vim /etc/redis/redis1_6379.conf

vim /etc/redis/redis2_6380.conf 5. 创建目录redis1_6379 和 redis2_6380

6. 启动 7. 查看是否启动

此时已经启动

其他两台同样的操作................

3.4.2 构建集群

1. 进入配置文件修改配置项（三台都要改）

启动

2. 构建集群

以下操作需要登录某个节点的redis数据库

redis-cli -h 192.168.156.3（进入数据库）

将其他节点加入集群
   CLUSTER MEET 192.168.156.3 6380
   CLUSTER MEET 192.168.156.4 6379
   CLUSTER MEET 192.168.156.4 6380
   CLUSTER MEET 192.168.156.5 6379
   CLUSTER MEET 192.168.156.5 6380

查看

分配slot
   redis-cli -p 6379 cluster addslots {0..5461}
   redis-cli -p 6380 cluster addslots {5462..10922}
   redis-cli -p 6380 cluster addslots {10923..16383}

建立主从关系
   redis-cli -p 6379 cluster replicate b356143b3ca4f07cceb30634618339ed107f793c
   redis-cli -p 6380cluster replicate 5cca472f9816273103769adb32b3a1b562f42655
   redis-cli -p 6380 cluster replicate 6d7219fd6db32e6014955edbeda26af6b59b9078