一、单点Redis的问题

主要有以下几个问题：

数据丢失问题。Redis是内存存储，服务重启可能会丢失数据。
并发能力问题。单节点Redis并发能力虽然不错，但也无法满足如618、双11这样的高并发场景。
故障恢复问题。如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段。
存储能力问题。Redis基于内存，单节点能存储的数据量难以满足海量数据需求。

二、Redis持久化

1.RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。Redis停机时会执行一次RDB。

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

RDB的其它配置也可以在redis.conf文件中设置：

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。 fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

2.AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

AOF的命令记录的频率也可以通过redis.conf文件来配：

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

3.开发时的小总结

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

三、Redis主从

1.搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

1）集群结构

具体的Docker安装Redis教程：https://blog.csdn.net/yueyue763184/article/details/127731964?spm=1001.2014.3001.5501

这里在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IP	PORT	角色
192.168.119.130	7001	master
192.168.119.130	7002	slave
192.168.119.130	7003	slave

Linux防火墙开端口命令：

firewall-cmd --zone=public --add-port=7001/tcp --permanent # 开放7001端口

firewall-cmd --reload # 重新加载

firewall-cmd --zone=public --list-ports # 查看所有开放的端口

2）准备实列和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。创建三个文件夹，名字分别叫7001、7002、7003：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir 7001 7002 7003

将其redis.conf中的持久化模式改为默认的RDB模式，AOF保持关闭状态：

虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息，格式如下：

# redis实例的声明 IP
replica-announce-ip 192.168.119.130

如果主库有密码，要在从库配置文件redis.conf中加入主库密码：

# 主redis数据库的密码
masterauth 123456

退出到tmp目录中将7001的redis.conf配置复制到7002、7003中：

cp 7001/redis.conf 7002

使用Docker启动命令（只以7001为例）：

docker run -itd --name redis7001 --privileged=true --restart=always --log-opt max-size=100m --log-opt max-file=2 -p 7001:6379 -v /tmp/7001/redis.conf:/etc/redis/redis.conf -v /tmp/7001/data:/data  redis redis-server /etc/redis/redis.conf --appendonly yes  --requirepass 123456

【 --restart=always】开机启动，失败也会一直重启；
【–log-opt max-size=100m】意味着一个容器日志大小上限是100M;
【–log-opt max-file=2】意味着一个容器有2个日志，分别是id+.json、id+1.json;
【-p 6379:6379】将宿主机6379端口与容器内6379端口进行映射；
【-v】将宿主机目录或文件与容器内目录或文件进行挂载映射；
【-itd】
i：以交互模式运行容器，通常与 -t 同时使用；
t：为容器重新分配一个伪输入终端，通常与 -i 同时使用；
d：表示后台启动redis；
【–name】给容器命名；
【–appendonly yes】开启redis 持久化；
【–requirepass 123456】强烈建议设置密码，并且将密码设置为高强度复杂；
【redis-server /etc/redis/redis.conf】以配置文件启动redis，加载容器内的conf文件；

启动成功：

3）开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

修改配置文件（永久生效）
在redis.conf中添加一行配置：slaveof <masterip> <masterport>
使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，与salveof效果一致。

首先进入7002，7003容器，添加临时的主从配置关系

docker exec -it redis7002 redis-cli

auth 123456

replicaof 192.168.119.130 7001

再进入主库7001查看消息：

info replication

随后可以去主库添加数据测试一下。

2.主从数据同步原理

1）全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。如图：

完整流程描述：

slave节点请求增量同步
master节点判断replid，发现不一致，拒绝增量同步
master将完整内存数据生成RDB，发送RDB到slave
slave清空本地数据，加载master的RDB
master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
slave执行接收到的命令，保持与master之间的同步

2）增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

3）repl_backlog原理

master怎么知道slave与自己的数据差异在哪里呢?这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

3.主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

三、Redis哨兵

1.哨兵的作用和原理

1）集群结构和作用

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构如图：

Sentinel 哨兵的作用如下：

监控：Sentinel 会不断检查您的master和slave是否按预期工作
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

2）集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

3）集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？流程如下：

sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

2.搭建哨兵集群

sentinel.conf配置文件：

port 27001
sentinel announce-ip 192.168.119.130
sentinel monitor mymaster 192.168.119.130 7001 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmp/s1"

其他细节可参考：https://blog.csdn.net/dongrixueyang/article/details/121632074

3.RedisTemplate的哨兵模式

Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

在pom.xml文件中引入：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

在配置文件application.yml中指定redis的sentinel相关信息：

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.119.130:27001
        - 192.168.119.130:27002
        - 192.168.119.130:27003

在项目的启动类中，添加一个新的bean：

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
    return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

这个bean中配置的就是读写策略，包括四种：

MASTER：从主节点读取
MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica
REPLICA：从slave（replica）节点读取
REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

四、Redis分片集群简单了解

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

海量数据存储问题
高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

集群中有多个master，每个master保存不同数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

分布式缓存——Redis集群