redis学习笔记(二)---集群

redis集群简介

首先为什么要集群呢，如果是单机版的redis，如果它挂了对我们程序的执行会有影响。
我们想要实现如果redis挂了会有其他redis顶上。而且单个redis的能力终究有限，我们可以把多个redis节点组成一个可用的工作节点，增加 Redis 的 高可用、可扩展、分布式、容错。

redis有三种集群模式

1. 主从模式
2. 哨兵模式
3. cluster模式

主从模式

主从模式简介

主从模式是三种里面最简单的，它将一台redis服务器里的数据复制到其他redis服务器中，前者称为 主节点(master)，后者称为 从节点(slave)。且数据的复制是 单向 的，只能由主节点到从节点。Redis 主从复制支持 主从同步 和 从从同步 两种，后者是 Redis 后续版本新增的功能，以减轻主节点的同步负担。

主从模式好处

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

主从模式工作机制

当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。
复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

主从模式测试

配置文件：在从服务器的配置文件中加入：slaveof
启动命令：redis-server 启动命令后加入 –slaveof
客户端命令：Redis 服务器启动后，直接通过客户端执行命令：slaveof ，让该 Redis 实例成为从节点。

1
2
3
4

# 创建一个端口为 6379 的 Redis 实例
redis-server --port 6379
# 创建一个端口为 6380 的 Redis 实例
redis-server --port 6380

此时两个redis服务都为主节点,然后我们在6380端口执行slave of 127.0.0.1 6379,使它变成从节点。

1
2
3
4
5

# 在 6380 端口的 Redis 实例中使用控制台
redis-cli -p 6380
# 成为本地 6379 端口实例的从节点
127.0.0.1:6380> SLAVEOF 127.0.0.1ø 6379
OK

主从模式原理

其中SYNC是非常耗时的操作。

1. 主服务器需要执行 BGSAVE 命令来生成 RDB 文件，这个生成操作会消耗主服务器大量的CPU、内存和磁盘 I/O 的资源。
2. 主服务器需要将自己生成的RDB文件发送给从服务器，这个发送操作会消耗主服务器 大量的网络资源 (带宽和流量)，并对主服务器响应命令请求的时间产生影响。
3. 接收到 RDB 文件的从服务器需要载入主服务器发来的 RBD 文件，并且在载入期间，从服务器会因为阻塞而没办法处理命令请求。

另外如果因为断线重连的情况出现，还要进行SYNC是很浪费的，因此redis2.8有了PSYNC命令来替代SYNC命令。

1. 全量复制：用于初次复制或其他无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。
2. 部分复制：用于网络中断等情况后的复制，只将 中断期间主节点执行的写命令 发送给 从节点，与全量复制相比更加高效。需要注意 的是，如果网络中断时间过长，导致主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制。

哨兵模式

哨兵模式简介

主从模式有个缺点，如果主redis服务器挂了，那就不能提供写的服务了。因此sentinel哨兵模式应运而生。顾名思义，它的作用就是监控redis集群的运行状况。

哨兵模式又两个部分组成，分别是哨兵节点和数据节点。
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

哨兵模式特点

在复制的基础上，哨兵实现了自动化的故障恢复功能。

1. 监控（Monitoring）： 哨兵会不断地检查主节点和从节点是否运作正常。
2. 自动故障转移（Automatic failover）： 当 主节点 不能正常工作时，哨兵会开始 3. 自动故障转移操作，它会将失效主节点的其中一个 从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
3. 配置提供者（Configuration provider）： 客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
4. 通知（Notification）： 哨兵可以将故障转移的结果发送给客户端。

哨兵模式测试

创建主从节点

首先创建主从配置文件，从文件如下

1
2
3
4
5
6
7
8
9
10

----redis-slave1.conf----
port 6380     //端口号
dbfilename "dump-6380.rdb" //文件名
daemonize yes //demonize是否以后台线程运行 在window没用
slaveof 127.0.0.1 6379 //设置主节点
----redis-slave2.conf---
port 6381
dbfilename "dump-6381.rdb"
daemonize yes
slaveof 127.0.0.1 6380

然后我们可以执行 redis-server 来根据配置文件启动不同的Redis 实例，依次启动主从节点。节点启动后执行redis-cli链接到主节点调用redis-cli命令查看主从状态。

创建哨兵节点

按照上面同样的方法，我们给哨兵节点也创建三个配置文件。(哨兵节点本质上是特殊的 Redis 节点，所以配置几乎没什么差别，只是在端口上做区分就好)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

----redis-sentinel1.conf---
port 16379
daemonize yes
logfile "redis-sentinel1.log"
sentinel monitor mymaster 127.0.0.1 6380 2
----redis-sentinel2.conf---
port 16380
daemonize yes
logfile "redis-sentinel2.log"
sentinel monitor mymaster 127.0.0.1 6380 2
----redis-sentinel3.conf---
port 16381
daemonize yes
logfile "redis-sentinel3.log"
sentinel monitor mymaster 127.0.0.1 6380 2

然后我们启动哨兵节点redis-server –sentinel。哨兵节点启动后redis-cli链接到哨兵节点，然后调用info Sentinel 命令来查看是否已经在监视主节点了。

故障模拟

使用taskkill /f /pid 杀掉主节点,然后等待一段时间，在去哨兵节点使用INFO SENTINEL命令查看节点状态

从上图可以发现新的主节点已经变成了6380端口的节点，同时还可以发现，哨兵节点认为新的主节点仍然有两个从节点 (上方 slaves=2)，这是因为哨兵在将 6380 切换成主节点的同时，将 6379 节点置为其从节点。虽然 6379 从节点已经挂掉，但是由于 哨兵并不会对从节点进行客观下线，因此认为该从节点一直存在。当 6379 节点重新启动后，会自动变成 6380 节点的从节点。
另外，在故障转移的阶段，哨兵和主从节点的配置文件都会被改写：

1. 对于主从节点： 主要是 slaveof 配置的变化，新的主节点没有了 slaveof 配置，其从节点则 slaveof 新的主节点。
2. 对于哨兵节点： 除了主从节点信息的变化，纪元(epoch) (记录当前集群状态的参数) 也会变化，纪元相关的参数都 +1 了。

主节点如何被推选出来

1. 在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被 淘汰。
2. 在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被 淘汰。
3. 在经历了以上两轮淘汰之后 剩下来的从服务器中,我们选出复制偏移量(replication offset)最大 的那个从服务器作为新的主服务器；如果复制偏移量不可用，或者从服务器的复制偏移量相同，那么带有最小运行ID的那个从服务器成为新的主服务器。

cluster模式

cluster模式简介

哨兵模式基本可以满足一般的生产需求，具有高可用。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

上图 展示了 Redis Cluster 典型的架构图，集群中的每一个 Redis 节点都 互相两两相连，客户端任意 直连 到集群中的 任意一台，就可以对其他 Redis 节点进行 读写 的操作。

cluster模式原理

redis 集群中内置了 16384 个哈希槽。当客户端连接到rRedis 集群之后，会同时得到一份关于这个 集群的配置信息，当客户端具体对某一个 key 值进行操作时，会计算出它的一个 Hash 值，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量 大致均等 的将哈希槽映射到不同的节点。