Redis最全资料

Redis的单线程和高性能 Redis是单线程吗&＃xff1f;

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的&＃xff0c;这也是 Redis 对外 提供键值存储服务的主要流程。但 Redis 的其他功能&＃xff0c;比如持久化、异步删除、集群数据同步等&＃xff0c;其实是由额外的线程执行的。

Redis 单线程为什么还能这么快&＃xff1f;

因为它所有的数据都在内存中&＃xff0c;所有的运算都是内存级别的运算&＃xff0c;而且单线程避免了多线程的切换性 能损耗问题。正因为 Redis 是单线程&＃xff0c;所以要小心使用 Redis 指令&＃xff0c;对于那些耗时的指令(比如 keys)&＃xff0c;一定要谨慎使用&＃xff0c;一不小心就可能会导致 Redis 卡顿。

Redis 单线程如何处理那么多的并发客户端连接&＃xff1f;

Redis的IO多路复用&＃xff1a;redis利用epoll来实现IO多路复用&＃xff0c;将连接信息和事件放到队列中&＃xff0c;依次放到 文件事件分派器&＃xff0c;事件分派器将事件分发给事件处理器。

命令&＃xff1a;info

Redis持久化

RDB快照&＃xff08;snapshot&＃xff09;dump.rdb

每次命令执行都会将所有redis内存快照到一个新的rdb文件里&＃xff0c;并覆盖原有rdb快照文件

• 自动方式

//默认开启
save 900 1
save 300 10
save 60 10000 //关闭RDB只需要将所有的save保存策略注释掉即可


• 手动方式
  redis客户端执行命令save或bgsave

bgsave的写时复制(COW)机制

Redis 借助操作系统提供的写时复制技术&＃xff08;Copy-On-Write, COW&＃xff09;&＃xff0c;在生成快照的同时&＃xff0c;依然可以正常 处理写命令。简单来说&＃xff0c;bgsave 子进程是由主线程 fork 生成的&＃xff0c;可以共享主线程的所有内存数据。 bgsave 子进程运行后&＃xff0c;开始读取主线程的内存数据&＃xff0c;并把它们写入 RDB 文件。此时&＃xff0c;如果主线程对这些 数据也都是读操作&＃xff0c;那么&＃xff0c;主线程和 bgsave 子进程相互不影响。但是&＃xff0c;如果主线程要修改一块数据&＃xff0c;那 么&＃xff0c;这块数据就会被复制一份&＃xff0c;生成该数据的副本。然后&＃xff0c;bgsave 子进程会把这个副本数据写入 RDB 文 件&＃xff0c;而在这个过程中&＃xff0c;主线程仍然可以直接修改原来的数据。

AOF&＃xff08;append-only file&＃xff09;

AOF 持久化&＃xff0c;将修改的每一条指令记录进文件appendonly.aof中(先写入os cache&＃xff0c;每隔一段时间 fsync到磁盘)

• 自动方式

appendonly yes //默认为no未开启
# 配置 Redis 多久才将数据 fsync 到磁盘一次
# 推荐&＃xff08;并且也是默认&＃xff09;的措施为每秒 fsync 一次&＃xff0c; 这种 fsync 策略可以兼顾速度和安全性
# appendfsync always&＃xff1a;每次有新命令追加到 AOF 文件时就执行一次 fsync &＃xff0c;非常慢&＃xff0c;也非常安全。 appendfsync everysec&＃xff1a;每秒 fsync 一次&＃xff0c;足够快&＃xff0c;并且在故障时只会丢失 1 秒钟的数据。
# appendfsync no&＃xff1a;从不 fsync &＃xff0c;将数据交给操作系统来处理。更快&＃xff0c;也更不安全的选择。


• 手动方式
  redis客户端执行命令bgrewriteaof
  AOF重写&＃xff1a;AOF文件里可能有太多没用指令&＃xff0c;所以AOF会定期根据内存的最新数据生成aof文件
  AOF重写redis会fork出一个子进程去做(与bgsave命令类似)&＃xff0c;不会对redis正常命令处理有太多 影响

# AOF重写配置auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写&＃xff0c;文件太小恢复速度本来就 很快&＃xff0c;重写的意义不大 auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写


Redis 4.0 混合持久化

AOF在重写时&＃xff0c;不再是单纯将内存数据转换为RESP命令写入AOF文件&＃xff0c;而是将 重写这一刻之前的内存做RDB快照处理&＃xff0c;并且将RDB快照内容和增量的AOF修改内存数据的命令存在一 起&＃xff0c;都写入新的AOF文件,并覆盖原appendonly.aof文件。

Redis 重启的时候&＃xff0c;可以先加载 RDB 的内容&＃xff0c;然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放&＃xff0c;因此重启效率大幅得到提升

# 开启aof
appendonly yes
# 混合持久化 前提aof必须开启
aof‐use‐rdb‐preamble yes


Redis数据备份策略&＃xff1a;

1. 写crontab定时调度脚本&＃xff0c;每小时都copy一份rdb或aof的备份到一个目录中去&＃xff0c;仅仅保留最近48 小时的备份
2. 每天都保留一份当日的数据备份到一个目录中去&＃xff0c;可以保留最近1个月的备份
3. 每次copy备份的时候&＃xff0c;都把太旧的备份给删了
4. 每天晚上将当前机器上的备份复制一份到其他机器上&＃xff0c;以防机器损坏

Redis主从工作原理

配置redis.conf

1、复制一份redis.conf文件2、将相关配置修改为如下值&＃xff1a;
port 6380
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1&＃xff08;bind绑定的是自己机器网卡的ip&＃xff0c;如果有多块网卡可以配多个ip&＃xff0c;代表允许客户端通过机器的哪些网卡ip去访问&＃xff0c;内网一般可以不配置bind&＃xff0c;注释掉即可&＃xff09;3、配置主从复制
replicaof 192.168.0.60 6379 # 从本机6379的redis实例复制数据&＃xff0c;Redis 5.0之前使用slaveof
replica‐read‐only yes # 配置从节点只读4、启动从节点
redis‐server redis.conf5、连接从节点
redis‐cli ‐p 63806、测试在6379实例上写数据&＃xff0c;6380实例是否能及时同步新修改数据7、可以自己再配置一个6381的从节点


主从工作原理

如果你为master配置了一个slave&＃xff0c;不管这个slave是否是第一次连接上Master&＃xff0c;它都会发送一个PSYNC命令给master请求复制数据。
master收到PSYNC命令后&＃xff0c;会在后台进行数据持久化通过bgsave生成最新的rdb快照文件&＃xff0c;持久化期间&＃xff0c;master会继续接收客户端的请求&＃xff0c;它会把这些可能修改数据集的请求缓存在内存中。
当持久化进行完毕以后&＃xff0c;master会把这份rdb文件数据集发送给slave&＃xff0c;slave会把接收到的数据进行持久化生成rdb&＃xff0c;然后再加载到内存中。然后&＃xff0c;master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时&＃xff0c;slave能够自动重连Master&＃xff0c;如果master收到了多个slave并发连接请求&＃xff0c;它只会进行一次持久化&＃xff0c;而不是一个连接一次&＃xff0c;然后再把这一份持久化的数据发送给多个并发连接的slave。

数据部分复制

当master和slave断开重连后&＃xff0c;一般都会对整份数据进行复制。但从redis2.8版本开始&＃xff0c;redis改用可以支
持部分数据复制的命令PSYNC去master同步数据&＃xff0c;slave与master能够在网络连接断开重连后只进行部分
数据复制(断点续传)。
master会在其内存中创建一个复制数据用的缓存队列&＃xff0c;缓存最近一段时间的数据&＃xff0c;master和它所有的
slave都维护了复制的数据下标offset和master的进程id&＃xff0c;因此&＃xff0c;当网络连接断开后&＃xff0c;slave会请求master
继续进行未完成的复制&＃xff0c;从所记录的数据下标开始。如果master进程id变化了&＃xff0c;或者从节点数据下标
offset太旧&＃xff0c;已经不在master的缓存队列里了&＃xff0c;那么将会进行一次全量数据的复制。

如果有很多从节点&＃xff0c;为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)&＃xff0c;可以做如
下架构&＃xff0c;让部分从节点与从节点(与主节点同步)同步数据

Redis哨兵高可用架构

sentinel哨兵是特殊的redis服务&＃xff0c;不提供读写服务&＃xff0c;主要用来监控redis实例节点。

哨兵架构下client端第一次从哨兵代理找出redis的主节点&＃xff0c;后续就直接访问redis的主节点&＃xff0c;不会每次都通过 sentinel代理访问redis的主节点&＃xff1b;
当redis的主节点发生变化&＃xff0c;哨兵会第一时间感知到&＃xff0c;并且将新的redis 主节点通知给client端(这里面redis的client端一般都实现了订阅功能&＃xff0c;订阅sentinel发布的节点变动消息)

1、复制一份sentinel.conf文件
cp sentinel.conf sentinel‐26379.conf2、将相关配置修改为如下值&＃xff1a;
port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis‐5.0.3/data"
# sentinel monitor
# quorum是一个数字&＃xff0c;指明当有多少个sentinel认为一个master失效时(值一般为&＃xff1a;sentinel总数/2 &＃43;1)&＃xff0c;master才算真正失效
sentinel monitor master 192.168.0.60 6379 2 # mymaster这个名字随便取&＃xff0c;客户端访问时会用到3、启动sentinel哨兵实例
src/redis‐sentinel sentinel‐26379.conf4、查看sentinel的info信息
src/redis‐cli ‐p 26379
127.0.0.1:26379>info
可以看到Sentinel的info里已经识别出了redis的主从5、可以自己再配置两个sentinel&＃xff0c;端口26380和26381&＃xff0c;注意上述配置文件里的对应数字都要修改


sentinel集群都启动完毕后&＃xff0c;会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的 最下面)&＃xff0c;我们查看下如下配置文件sentinel-26379.conf&＃xff0c;如下所示&＃xff1a;

sentinel known‐replica master 192.168.0.60 6380 #代表从节点信息
sentinel known‐replica master 192.168.0.60 6381 #代表从节点信息
sentinel known‐sentinel master 192.168.0.60 26380 fc03b6ce7c3c56952d0a5d70c1f90475b4 a5d70c #代表感知到的其它哨兵节点
sentinel known‐sentinel master 192.168.0.60 26381 6ebb8e1686438ba8e9f530d3882f8043f7 86438b #代表感知到的其它哨兵节点


当redis主节点如果挂了&＃xff0c;哨兵集群会重新选举出新的redis主节点&＃xff0c;同时会修改所有sentinel节点配置文件 的集群元数据信息&＃xff0c;比如6379的redis如果挂了&＃xff0c;假设选举出的新主节点是6380&＃xff0c;则sentinel文件里的集 群元数据信息会变成如下所示&＃xff1a;

sentinel known‐replica master 192.168.0.60 6379 #代表从节点信息
sentinel known‐replica master 192.168.0.60 6381 #代表从节点信息
sentinel known‐sentinel master 192.168.0.60 26380 fc03b6ce7c3c56952d0a5d70c1f90475b4 a5d70c #代表感知到的其它哨兵节点
sentinel known‐sentinel master 192.168.0.60 26381 6ebb8e1686438ba8e9f530d3882f8043f7 86438b #代表感知到的其它哨兵节点#同时还会修改sentinel文件里之前配置的master对应的6379端口&＃xff0c;改为6380
sentinel monitor master 192.168.0.60 6380 2


当6379的redis实例再次启动时&＃xff0c;哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点 加入集群

哨兵leader选举流程

当一个master服务器被某sentinel视为下线状态后&＃xff0c;该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。

每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的 leader&＃xff0c;选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)&＃xff0c;每个纪元中只会选择一 个sentinel的leader。

如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作&＃xff0c;从存活的slave中选举出新的master&＃xff0c;这个选举过程跟集群的master选举很类似。

哨兵集群只有一个哨兵节点&＃xff0c;redis的主从也能正常运行以及选举master&＃xff0c;如果master挂了&＃xff0c;那唯一的那个哨兵节点就是哨兵leader了&＃xff0c;可以正常选举新master。 不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点 类似。

sentinel总结&＃xff1a;

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态&＃xff0c;如果master节点异常&＃xff0c;则会做主从切换&＃xff0c;将某一台slave作为master&＃xff0c;
哨兵的配置略微复杂&＃xff0c;并且性能和高可用性等各方面表现一般&＃xff0c;
特别是在主从切换的瞬间存在访问瞬断的情况&＃xff0c;
而且哨兵模式只有一个主节点对外提供服务&＃xff0c;没法支持很高的并发&＃xff0c;
且单个主节点内存也不宜设置得过大&＃xff0c;否则会导致持久化文件过大&＃xff0c;影响数据恢复或主从同步的效率

高可用集群模式

redis集群是一个由多个主从节点群组成的分布式服务器群&＃xff0c;它具有复制、高可用和分片特性。
Redis集群不需要sentinel哨兵∙也能完成节点移除和故障转移的功能。
需要将每个节点设置成集群模式&＃xff0c;这种集群模式没有中心节点&＃xff0c;可水平扩展&＃xff0c;据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。
redis集群的性能和高可用性均优于之前版本的哨兵模式&＃xff0c;且集群配置非常简单。

redis集群搭建

#第一步&＃xff1a;在第一台机器的/usr/local下创建文件夹redis‐cluster&＃xff0c;然后在其下面分别创建2个文件夾如下&＃xff1a;
&＃xff08;1&＃xff09;mkdir ‐p /usr/local/redis‐cluster
&＃xff08;2&＃xff09;mkdir 8001 8004#第二步&＃xff1a;把之前的redis.conf配置文件copy到8001下&＃xff0c;修改如下内容&＃xff1a;
&＃xff08;1&＃xff09;daemonize yes #yes允许后台启动
&＃xff08;2&＃xff09;port 8001 #&＃xff08;分别对每个机器的端口号进行设置&＃xff09;
&＃xff08;3&＃xff09;pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件
&＃xff08;4&＃xff09;dir /usr/local/redis‐cluster/8001/ #&＃xff08;指定数据文件存放位置&＃xff0c;必须要指定不同的目录位置&＃xff0c;不然会 丢失数据&＃xff09;
&＃xff08;5&＃xff09;cluster‐enabled yes #&＃xff08;启动集群模式&＃xff09;
&＃xff08;6&＃xff09;cluster‐config‐file nodes‐8001.conf #&＃xff08;集群节点信息文件&＃xff0c;这里800x最好和port对应上&＃xff09;
&＃xff08;7&＃xff09;cluster‐node‐timeout 10000 #表示当某个节点持续 timeout 的时间失联时&＃xff0c;才可以认定该节点出现故障&＃xff0c;需要进行主从切换
&＃xff08;8&＃xff09;# bind 127.0.0.1&＃xff08;bind绑定的是自己机器网卡的ip&＃xff0c;如果有多块网卡可以配多个ip&＃xff0c;代表允许客户端通 过机器的哪些网卡ip去访问&＃xff0c;内网一般可以不配置bind&＃xff0c;注释掉即可&＃xff09;
&＃xff08;9&＃xff09;protected‐mode no #&＃xff08;关闭保护模式&＃xff09; #protected-mode 是3.2 之后加入的新特性&＃xff0c;为了禁止公网访问redis cache&＃xff0c;加强redis安全的。根据自己需要配置&＃xff0c;它启用的条件&＃xff0c;有两个&＃xff0c;没有bind IP 以及没有设置访问密码
&＃xff08;10&＃xff09;appendonly yes
#如果要设置密码需要增加如下配置&＃xff1a;
&＃xff08;11&＃xff09;requirepass mypass #(设置redis访问密码)
&＃xff08;12&＃xff09;masterauth mypass #(设置集群节点间访问密码&＃xff0c;跟上面一致)#第三步&＃xff1a;把修改后的配置文件&＃xff0c;copy到8004&＃xff0c;修改第2、3、4、6项里的端口号&＃xff0c;可以用批量替换&＃xff1a; :%s/源字符串/目的字符串/g #第四步&＃xff1a;另外两台机器也需要做上面几步操作&＃xff0c;第二台机器用8002和8005&＃xff0c;第三台机器用8003和8006 #第五步&＃xff1a;分别启动6个redis实例&＃xff0c;然后检查是否启动成功
&＃xff08;1&＃xff09;/usr/local/redis‐5.0.3/src/redis‐server /usr/local/redis‐cluster/800*/redis.conf
&＃xff08;2&＃xff09;ps ‐ef | grep redis 查看是否启动成功#第六步&＃xff1a;用redis‐cli创建整个redis集群(redis5以前的版本集群是依靠ruby脚本redis‐trib.rb实现)
# 下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问&＃xff0c;可以先简单把所有机器防火墙关掉&＃xff0c;如果不 关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# 关闭防火墙
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动 # 注意&＃xff1a;下面这条创建集群的命令大家不要直接复制&＃xff0c;里面的空格编码可能有问题导致创建集群不成功
/usr/local/redis‐5.0.3/src/redis‐cli ‐a mypass ‐‐cluster create ‐‐cluster‐replicas 1 1 92.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006#第七步&＃xff1a;验证集群&＃xff1a;
&＃xff08;1&＃xff09;连接任意一个客户端即可&＃xff1a;./redis‐cli ‐c ‐h ‐p (‐a访问服务端密码&＃xff0c;‐c表示集群模式&＃xff0c;指定ip地址 和端口号&＃xff09;
如&＃xff1a;/usr/local/redis‐5.0.3/src/redis‐cli ‐a mypass ‐c ‐h 192.168.0.61 ‐p 800*
&＃xff08;2&＃xff09;进行验证&＃xff1a; cluster info&＃xff08;查看集群信息&＃xff09;、cluster nodes&＃xff08;查看节点列表&＃xff09;
&＃xff08;3&＃xff09;进行数据操作验证
&＃xff08;4&＃xff09;关闭集群则需要逐个进行关闭&＃xff0c;使用命令&＃xff1a;
/usr/local/redis‐5.0.3/src/redis‐cli ‐a mypass ‐c ‐h 192.168.0.60 ‐p 800* shutdown


Redis集群原理分析

槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值&＃xff0c;然后用这个整数值对 16384 进行取模 来得到具体槽位。
HASH_SLOT &＃61; CRC16(key) mod 16384

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)&＃xff0c;每个节点负责其中一部分槽位。槽位的信息存储于每 个节点中。 当 Redis Cluster 的客户端来连接集群时&＃xff0c;它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这 样当客户端要查找某个 key 时&＃xff0c;可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不 一致的情况&＃xff0c;还需要纠正机制来实现槽位信息的校验调整。

跳转重定位

当客户端向一个错误的节点发出了指令&＃xff0c;该节点会发现指令的 key 所在的槽位并不归自己管理&＃xff0c;这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址&＃xff0c;告诉客户端去连这个节点去获取数据。客户端收到指 令后除了跳转到正确的节点上去操作&＃xff0c;还会同步更新纠正本地的槽位映射表缓存&＃xff0c;后续所有 key 将使用新的槽位映射表

Redis集群节点间的通信机制

redis cluster节点间采取gossip协议进行通信&＃xff1b;
维护集群的元数据(集群节点信息&＃xff0c;主从角色&＃xff0c;节点数量&＃xff0c;各节点共享的数据等)有两种方式&＃xff1a;集中式和gossip

• 集中式&＃xff1a;&＃xff08;强一致性&＃xff09;
  优点&＃xff1a;在于元数据的更新和读取&＃xff0c;时效性非常好&＃xff0c;一旦元数据出现变更立即就会更新到集中式的存储中&＃xff0c;其他节点读取的时候立即就可以立即感知到&＃xff1b;
  缺点&＃xff1a;所有的元数据的更新压力全部集中在一个地方&＃xff0c;可能导致元数据的存储压力。 很多中间件都会借助zookeeper集中式存储元数据。
• gossip&＃xff1a;gossip协议包含多种消息&＃xff0c;包括ping&＃xff0c;pong&＃xff0c;meet&＃xff0c;fail等等。 &＃xff08;最终一致性&＃xff09;

1. meet&＃xff1a;某个节点发送meet给新加入的节点&＃xff0c;让新节点加入集群中&＃xff0c;然后新节点就会开始与其他节点进行通信&＃xff1b;
2. ping&＃xff1a;每个节点都会频繁给其他节点发送ping&＃xff0c;其中包含自己的状态还有自己维护的集群元数据&＃xff0c;互相通过 ping交换元数据(类似自己感知到的集群节点增加和移除&＃xff0c;hash slot信息等)&＃xff1b;
3. pong: 对ping和meet消息的返回&＃xff0c;包含自己的状态和其他信息&＃xff0c;也可以用于信息广播和更新&＃xff1b;
4. fail: 某个节点判断另一个节点fail之后&＃xff0c;就发送fail给其他节点&＃xff0c;通知其他节点&＃xff0c;指定的节点宕机了。

优点&＃xff1a;在于元数据的更新比较分散&＃xff0c;不是集中在一个地方&＃xff0c;更新请求会陆陆续续&＃xff0c;打到所有节点上去更新&＃xff0c;有一定的延时&＃xff0c;降低了压力&＃xff1b;

缺点&＃xff1a;在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

gossip通信的10000端口
每个节点都有一个专门用于节点间gossip通信的端口&＃xff0c;就是自己提供服务的端口号&＃43;10000&＃xff0c;比如7001&＃xff0c;那么 用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息&＃xff0c;同时其他几 点接收到ping消息之后返回pong消息。

网络抖动

真实世界的机房网络往往并不是风平浪静的&＃xff0c;它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象&＃xff0c;突然之间部分连接变得不可访问&＃xff0c;然后很快又恢复正常。
为解决这种问题&＃xff0c;Redis Cluster 提供了一种选项cluster­node­timeout&＃xff0c;表示当某个节点持续 timeout 的时间失联时&＃xff0c;才可以认定该节点出现故障&＃xff0c;需要进行主从切换。如果没有这个选项&＃xff0c;网络抖动会导致主从频繁切换 (数据的重新复制)

Redis集群选举原理分析

当slave发现自己的master变为FAIL状态时&＃xff0c;便尝试进行Failover&＃xff0c;以期成为新的master。由于挂掉的master 可能会有多个slave&＃xff0c;从而存在多个slave竞争成为master节点的过程&＃xff0c; 其过程如下&＃xff1a;
1.slave发现自己的master变为FAIL
2.将自己记录的集群currentEpoch(即选举周期)加1&＃xff0c;并广播FAILOVER_AUTH_REQUEST(故障转移验证请求信息)
3.其他节点收到该信息&＃xff0c;只有master响应&＃xff0c;判断请求者的合法性&＃xff0c;并发送FAILOVER_AUTH_ACK(故障转移验证确认信息) &＃xff0c;对每一个 epoch只发送一次ack
4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点&＃xff0c;如果只有两个&＃xff0c;当其中一个挂了&＃xff0c;只剩一个主节点是不能选举成功的)
6.slave广播Pong消息通知其他集群节点。

从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举&＃xff0c;而是有一定延迟&＃xff0c;一定的延迟确保我们等待 FAIL状态在集群中传播&＃xff0c;slave如果立即尝试选举&＃xff0c;其它masters或许尚未意识到FAIL状态&＃xff0c;可能会拒绝投票 。
延迟计算公式&＃xff1a; DELAY &＃61; 500ms &＃43; random(0 ~ 500ms) &＃43; SLAVE_RANK * 1000ms
SLAVE_RANK越小代表已复制的数据越新。这种方式下&＃xff0c;持有最新数据的slave将会首先发起选举&＃xff08;理论上&＃xff09;。

集群脑裂数据丢失问题

redis集群没有过半机制会有脑裂问题&＃xff0c;网络分区导致脑裂后多个主节点对外提供写服务&＃xff0c;一旦网络分区恢复&＃xff0c; 会将其中一个主节点变为从节点&＃xff0c;这时会有大量数据丢失。 规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失&＃xff0c;参考集群leader选举机制)&＃xff1a;

min‐replicas‐to‐write 1 //写数据成功最少同步的slave数量&＃xff0c;这个数量可以模仿大于半数机制配置&＃xff0c;比如 集群总共三个节点可以配置1&＃xff0c;加上leader就是2&＃xff0c;超过了半数
#注意&＃xff1a;这个配置在一定程度上会影响集群的可用性&＃xff0c;比如slave要是少于1个&＃xff0c;这个集群就算leader正常也不能提供服务了&＃xff0c;需要具体场景权衡选择。


集群是否完整才能对外提供服务

当redis.conf的配置cluster-require-full-coverage为no时&＃xff0c;表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时&＃xff0c;集群仍然可用&＃xff0c;如果为yes则集群不可用

Redis集群为什么至少需要三个master节点&＃xff0c;并且推荐节点数为奇数&＃xff1f;

因为新master的选举需要大于半数的集群master节点同意才能选举成功&＃xff0c;如果只有两个master节点&＃xff0c;当其中 一个挂了&＃xff0c;是达不到选举新master的条件的。
奇数个master节点可以在满足选举该条件的基础上节省一个节点&＃xff0c;比如三个master节点和四个master节点的 集群相比&＃xff0c;大家如果都挂了一个master节点都能选举新master节点&＃xff0c;如果都挂了两个master节点都没法选举 新master节点了&＃xff0c;所以奇数的master节点更多的是从节省机器资源角度出发说的。

Redis集群对批量操作命令的支持

对于类似mset&＃xff0c;mget这样的多个key的原生批量操作命令&＃xff0c;redis集群只支持所有key落在同一slot的情况&＃xff0c;如果有多个key一定要用mset命令在redis集群上操作&＃xff0c;则可以在key的前面加上{XX}&＃xff0c;这样参数数据分片hash计算的只会是大括号里的值&＃xff0c;这样能确保不同的key能落到同一slot里去&＃xff0c;示例如下&＃xff1a;

mset {user1}:1:name xiaoming {user1}:1:age 18


假设name和age计算的hash slot值不一样&＃xff0c;但是这条命令在集群下执行&＃xff0c;redis只会用大括号里的 user1 做 hash slot计算&＃xff0c;所以算出来的slot值肯定相同&＃xff0c;最后都能落在同一slot

Redis 实现分布式锁

1.基本命令方式&＃xff1a;

Redis 实现分布式锁的核心命令&＃xff1a;
SETNX key value

通常为了避免死锁&＃xff0c;我们会为锁设置一个超时时间&＃xff0c;在 Redis 中可以通过 expire 命令来进行实现&＃xff1a;
EXPIRE key seconds

使用 Jedis 客户端来进行实现&＃xff0c;其代码如下&＃xff1a;

Long result &＃61; jedis.setnx("lockKey", "lockValue");
if (result &＃61;&＃61; 1) { // 如果此处程序被异常终止(如直接kill -9进程)&＃xff0c;则设置超时的操作就无法进行&＃xff0c;该锁就会出现死锁 jedis.expire("lockKey", 3);
}


官方文档中推荐直接使用 set 命令来进行实现&＃xff1a;
SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]
这里我们主要关注以下四个参数&＃xff1a;
「EX」 &＃xff1a;设置超时时间&＃xff0c;单位是秒&＃xff1b;
「PX」 &＃xff1a;设置超时时间&＃xff0c;单位是毫秒&＃xff1b;
「NX」 &＃xff1a;当且仅当对应的 Key 不存在时才进行设置&＃xff1b;
「XX」 &＃xff1a;当且仅当对应的 Key 存在时才进行设置。

jedis.set("lockKey", "lockValue", SetParams.setParams().nx().ex(3));


此时一条命令就可以完成值和超时时间的设置&＃xff0c;并且因为只有一条命令&＃xff0c;因此其原子性也得到了保证。但因为引入了超时时间来避免死锁&＃xff0c;同时也引出了其它两个问题&＃xff1a;

• 问题一&＃xff1a;当业务处理的时间超过过期时间后(图中进程 A)&＃xff0c;由于锁已经被释放&＃xff0c;此时其他进程就可以获得该锁(图中进程 B)&＃xff0c;这意味着有两个进程(A 和 B)同时进入了临界区&＃xff0c;此时分布式锁就失效了&＃xff1b;
• 问题二&＃xff1a;如上图所示&＃xff0c;当进程 A 业务处理完成后&＃xff0c;此时删除的是进程 B 的锁&＃xff0c;进而导致分布式锁又一次失效&＃xff0c;让进程 B 和 进程 C 同时进入了临界区。
  针对问题二&＃xff0c;我们可以在创建锁时为其指定一个唯一的标识作为 Key 的 Value&＃xff0c;这里假设我们采用 UUID &＃43; 线程ID 来作为唯一标识&＃xff1a;

String identifier &＃61; UUID.randomUUID() &＃43; ":" &＃43; Thread.currentThread().getId();
jedis.set("LockKey", identifier, SetParams.setParams().nx().ex(3));


然后在删除锁前&＃xff0c;先将该唯一标识与锁的 Value 值进行比较&＃xff0c;如果不相等&＃xff0c;证明该锁不属于当前的操作对象&＃xff0c;此时不执行删除操作。为保证判断操作和删除操作整体的原子性&＃xff0c;这里需要使用 Lua 脚本来执行&＃xff1a;

这段脚本的意思是如果 value 的值与给定的值相同&＃xff0c;则执行删除命令&＃xff0c;否则直接返回状态码 0 。对应使用 Jedis 实现的代码如下&＃xff1a;

String script &＃61; "if redis.call(&＃39;get&＃39;, KEYS[1]) &＃61;&＃61; ARGV[1] then return redis.call(&＃39;del&＃39;, KEYS[1]) else return 0 end";
// 脚本,keys的集合,argvs的集合
jedis.eval(script,Collections.singletonList("LockKey"),Collections.singletonList("identifier "));


接着再看问题一&＃xff0c;问题一最简单的解决方法是&＃xff1a;你可以估计业务的最大处理时间&＃xff0c;然后保证设置的过期时间大于最大处理时间。但是由于业务会面临各种复杂的情况&＃xff0c;因此可能无法保证业务每一次都能在规定的过期时间内处理完成&＃xff0c;此时可以使用延长锁时效的策略。
1.3 延长锁时效
延长锁时效的方案如下&＃xff1a;假设锁超时时间是 30 秒&＃xff0c;此时程序需要每隔一段时间去扫描一下该锁是否还存在&＃xff0c;扫描时间需要小于超时时间&＃xff0c;通常可以设置为超时时间的 1/3&＃xff0c;在这里也就是 10 秒扫描一次。如果锁还存在&＃xff0c;则重置其超时时间恢复到 30 秒。通过这种方案&＃xff0c;只要业务还没有处理完成&＃xff0c;锁就会一直有效&＃xff1b;而当业务一旦处理完成&＃xff0c;程序也会马上删除该锁。

Redis 的 Java 客户端 Redisson 提供的分布式锁就支持类似的延长锁时效的策略&＃xff0c;称为 WatchDog&＃xff0c;直译过来就是 “看门狗” 机制。

Redis 6.0 只有在网络请求的接收和解析&＃xff0c;以及请求后的数据通过网络返回给时&＃xff0c;使用了多线程。而数据读写操作还是由单线程来完成的