[大数据]缓存服务——Redis集群（2）

缓存服务——Redis集群（2）

五、Redis主从复制

1.redis复制特性

● 使用异步复制

● 一个主服务器可以有多个从服务器

● 从服务器也可以有自己的从服务器

● 复制功能不会阻塞主服务器

● 可以通过复制功能来让主服务器免予执行持久化操作，由从服务器去执行持久化操作即可。

● 关闭主服务器持久化时，复制功能的数据安全

当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。

为了帮助理解服务器关闭持久化时自动拉起的危险性。参考以下导致主从服务数据全部丢失的例子：

● 假设节点A为主服务器，并且关闭了持久化。并且节点B和节点C从节点A复制数据。

● 节点A崩渍，然后由自动拉起服务重启了节点A，由于节点A的持久化被关闭了，所以重启之后没有任何数据。

● 节点B和节点C将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。

在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现 Redis 的高可用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。

无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。

2.redis主从复制原理

①redis主从同步方式

redis主从同步有两种方式（两个阶段）：全同步和部分同步。

主从刚刚连接的时候，进行全同步；全同步结束后，进行部分同步。当然，如果有需要，slave 在任何时候都可以发起全同步。

redis 策略是，无论如何，首先会尝试进行部分同步，如果不成功，要求从机进行全同步，并启动 BGSAVE。

BGSAVE结束后，传输RDB文件；如果成功，允许从机进行部分同步，并传输积压空间中的数据。

下面这幅图，总结了主从同步的机制：

②主从复制原理

1.从服务器向主服务器发送SYNC命令。

2.接到SYNC命令的主服务器会调用BGSAVE命令，创建一个RDB文件，并使用缓冲区纪录下来的执行所有写命令。

3.当主服务器执行完BGSAVE命令时，它会向从服务器发送RDB文件，而从服务器则会接收并载入这个文件。

4.主服务器将缓冲区储存的所有写命令发送给从服务器执行，这个操作被称为“命令传播”（command propagate）。

命令传播是一个持续的过程：只要复制仍在继续，命令传播就会一直进行，主从服务器的状态可一直保持一致。

③redis复制中的SYNC和PSYNC

在Redis 2.8版本之前，断线之后重连的从服务器总要执行一次完整重同步（full resynchronization) 操作。

从Redis 2.8 开始，Redis 使用PSYNC命令代替SYNC命令。PSYNC比起SYNC的最大改进在于 PSYNC实现了部分重同步（partial resync）只要条件允许，PSYNC可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。

④redis复制的一致性问题

在读写分离环境下，客户端向主服务器发送写命令SET n 10086，主服务器在执行这个写命令之后，向客户端返回回复，并将这个写命令传播给从服务器。

接到回复的客户端继续向从服务器发送读命令GET n，并且因为网络状态的原因，客户端的GET命令比主服务器传播的SET命令更快到达了从服务器。

因为从服务器键n的值还未被更新，所以客户端在从服务器读取到的将是一个错误 (过期) 的n值。

⑤redis复制安全性提升

主服务器只在有至少N个从服务器的情况下，才执行写操作。从Redis2.8开始，为了保证数据的安全性，可以通过配置， 让主服务器只在有至少N个当前已连接从服务器的情况下，才执行写命令。

不过，因为Redis使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此，数据丢失的可能性仍然是存在的。

通过以下两个参数保证数据的安全：

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

3.redis主从复制搭建

#安装redis服务
#配置master节点
[root@master opt]# vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行,修改监听地址为0.0.0.0
daemonize yes                       #137行，开启守护进程
logfile /var/ log/redis_6379.log    #172行，指定日志文件目录
dir /var/lib/redis/6379             #264行，指定工作目录
appendonly yes                      #700行，修改为yes开启AOF持久化功能

[root@master opt]# /etc/init.d/redis_6379 restart

#配置slave1,2节点
[root@slave1 opt]# vim /etc/redis/6379.conf
bind 0.0.0.0                       #70行，修改监听地址为0.0.0.0
daemonize yes                      #137行，开启守护进程
logfile /var/log/redis_6379.log    #172行，指定日志文件目录
dir /var/lib/redis/6379            #264行，指定工作目录
replicaof 192.168.222.30 6379      #288行，指定要同步的Master节点IP和端口
appendonly yes                     #700行，开启AOF持久化功能

[root@slave1 opt]# /etc/init.d/redis_6379 restart

#redis主从复制管理
#主从复制状态监控：info replication
[root@master opt]# redis-cli info replication
#或：
[root@master opt]# redis-cli
127.0.0.0:6379>info replication

#主从切换：
127.0.0.0:6379>slaveof no one

六、Redis HA（Redis Sentinel）哨兵模式

官方文档：https://redis.io/docs/manual/sentinel/

redis-sentinel是redis官方推荐的高可用性（HA）解决方案，当用redis做master-slave的高可用方案时，假如master宕机了，redis本身（包括它的很多客户端）都没有实现自动进行主备切换，而redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

sentinel是一个监视器，它可以根据被监视实例的身份和状态来判断应该执行何种动作。

1.Redis Sentinel功能

1.1 监控（Monitoring）

sentinel会不断地检查你的主服务器和从服务器是够运作正常。

1.2 提醒（Notification）

当被监控的某个redis服务器出现问题时，sentinel可以通过API向管理员或者其它应用程序发送通知。

1.3 自动故障迁移（Automatic faliover）

当一个主服务器不能正常工作时，sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其它从服务器改为复制新的主服务器；当客户端试图链接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

2.Redis Sentinel服务器连接

2.1 发现并连接主服务器

sentinel通过用户给定的配置文件来发现主服务器。

sentinel会与被监视的主服务器创建

两个网络连接：

● 命令连接用于向主服务器发送命令。

● 订阅连接用于订阅指定的频道，从而发现。

● 监视同一主服务器的其它sentinel。

2.2 发现并连接从服务器

sentinel通过向主服务器发送INFO命令来自动获得所有从服务器的地址。

跟主服务器一样，sentinel会与每个被发现的从服务器创建命令连接和订阅连接。

2.3 发现其它sentinel

sentinel会通过命令连接向被监视的主从服务器发送“HELLO”信息，该信息包含sentinel的IP、端口号、ID等内容，以此来向其它sentinel宣告自己的存在。与此同时sentinel会通过订阅连接接收其它sentinel的“HELLO”信息，以此来发现监视通一个主服务器的其它sentinel。

sentinel1通过发送HELLO信息来sentinel2和sentinel3发现自己，其它两个sentinel也会进行类似的操作。

2.4 多个sentinel之间的链接

sentinel之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收HELLO信息的中介，所以sentinel之间不会创建订阅连接。

3.Redis Sentinel检测实例的状态

sentinel使用ping命令来检测实例的状态：如果实例在指定的时间内没有返回回复，那么该实例会被sentinel判断为下线。

Redis的Sentinel中关于下线（down）有两个不同的概念：

● 主观下线(Subjectively Down，简称SDOWN）指的是单个sentinel实例对服务器做出的下线判断。

● 客观下线(Objectively Down，简称ODOWN）指的是多个sentinel实例在对用一个服务器做出SDOWN判断，并且通过SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线决定。（一个Sentinel可以通过向另一个Sentinel发送SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

如果一个服务器没有在master-down-after-milliseconds选项所指定的时间内，对向它发送PING命令的Sentinel返回一个有效回复（valid reply），那么Sentinel就会将这个服务器记为主观下线。

4.Redis Sentinel故障转移FAILOVER

一次故障转移操作由以下步骤组成：

● 发现主服务器已经进入客观下线状态。

● 基于Raft leader election协议，进行投票选举

● 如果当选失败，那么在设定的故障迁移超过时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。

● 选出一个从服务器，并将它升级为主服务器。

● 向被选中的从服务器发送SLAVEOF NO ONE命令，让它转变为主服务器。

● 通过发布与订阅功能，将更新后的配置传播给所有其他Sentinel，其他Sentinel对它们自己的配置进行更新。

● 向已下线主服务器的从服务器发送SLAVEOF命令，让它们去复制新的主服务器。

● 当所有从服务器都已经开始复制新的主服务器时，leader sentinel终止这次故障迁移操作。

5.Redis Sentinel配置

#修改redis哨兵模式的配置文件（所有节点）
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no                                    #17行，关闭保护模式
port 26379                                           #21行，Redis哨兵默认的监听端口
daemonize yes                                        #26行，指定sentinel为后台启动
logfile "/var/1og/sentinel.log"                      #36行，指定日志存放路径
dir "/var/lib/redis/6379"                            #65行，指定数据库存放路径
sentinel monitor mymaster 192.168.222.30 6379 2     #84行，修改,指定该哨兵节点监控192.168.222.30:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关:至少需要2
个哨兵节点同意，才能 判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 3000       #113行，判定服务器down掉的时间周期，默认30000毫秒(30秒 )
sentinel failover-timeout mymaster 180000            #146行，故障节点的最大超时时间为180000 (180秒)

#启动哨兵模式（先启master再启slave）
cd /opt/redis-5.0.7/ 
redis-sentinel sentinel.conf &	#后台启动
#查看哨兵信息
redis-cli -p 26379 info sentinel

#配置文件说明
# 指定监控master
sentinel monitor mymaster 127.0.0.1 6379 2
# {2表示多少个 sentinel 同意)
# 安全信息
I
sentinel auth-pass mymaster root
# 超过15000毫秒后认为主机宕机
sentinel down-after-milliseconds mymaster 15000
# 当主从切换多久后认为主从切换失败
sentinel failover-timeout mymaster 900000
# 这两个配置后面的数量主从机需要一样, epoch为master的版本
sentinel leader-epoch mymaster 1
sentinel config-epoch mymaster 1

6.Redis Sentinel命令操作

7.Redis Sentinel发布与订阅信息

客户端可以将sentinel看做是一个只提供了订阅功能的redis服务器：你不可以使用PUBLISH命令向这个服务器发送信息，但你可以用SUBSCRIBE命令或者PSUBSCRIBE命令，通过订阅给定的频道来获取相应的事件提醒。

一个频道能够接收和这个频道的名字相同的事件。比如说：+sdown的频道就可以接受所有实例进入主观下线（SDOWN）状态的事件。

通过执行PSUBSCRIBE *命令可以接受所有事件信息。

以下列出的是客户端可以通过订阅来获得的频道和信息的格式：

• 第一个英文单词是频道/事件的名字，其余的是数据的格式。

注意，当格式中包含instance details字样时，表示频道所返回的信息中包含了以下用于识别目标实例的内容：

<instance details><name><ip><port> @ <master-name><master-ip><master-port>
@字符之后的内容用于指定主服务器，这些内容是可选的，它们仅在@字符之前的内容指定的实例不是主服务器时使用。

七、Redis Cluster集群

1.Redis Cluster介绍

Redis在3.0版正式引入reids-cluster集群这个特性。redis集群是一个提供在多个redis间节点间共享数据的程序集。redis集群是一个分布式、容错的redis内存K/V服务，集群可以使用的功能是普通单机redis所能使用的功能的一个子集，比如redis集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像redis那样的性能，在高负载的情况下可能会导致不可预料的错误。还有比如set里的并集和交集操作，就没有实现。通常来说，那些处理命令的节点获取不到键值的所有操作都不会被实现。在将来，用户或许可以通过使用MIGRATE COPY命令，在集群上用计算节点来执行多键值的只读操作，但reids集群本身不会执行复杂的多键值操作来把键值在节点间移来移去。redis集群不像单机版本的redis那样支持多个数据库，集群只有数据库0，而且也不支持select命令。redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下继续处理命令。

• redis集群是一个可以在多个redis节点之间进行数据共享的设施。
• redis集群不支持那些需要同时处理多个键的redis命令，因为执行这些命令需要在多个redis节点之间移动数据，并且在高负载的情况下，这些命令将降低redis集群的性能，并导致不可预测的行为。
• redis集群通过分区来提供一定程度的可用性：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。将数据自动切分到多个节点的能力。
• 当集群中的一部分节点失效或者无法进行通讯时，仍然可以继续处理命令请求的能力。

2.Redis Cluster集群的优点

无中心架构，分布式提供服务。数据按照slot存储分布在多个redis实例上。增加slave做standby数据副本，用于failover，使集群快速回复。实现故障auto failover，节点之间通过gossip协议交换状态信息；投票机制完成salve到master角色的提升。支持在线增加或减少节点。降低硬件成本和运维成本，提高系统的扩展性和可用性。

3.Redis Cluster集群的缺点

client实现复杂，驱动要求实现smart client，缓存slots mapping信息并及时更新。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。客户端的不成熟，影响应用的稳定性，提高开发难度。节点会因为某些原因发生阻塞（阻塞大于cluster-node-timeout），被判断下线。这种failover是没有必要，sentinel也存在这种切换场景。

4.Redis Cluster参考资料

参考：https://redis.io/docs/manual/scaling/

集群部署交互式命令行工具：https://github.com/eyjian/redis-tools/tree/master/deploy

集群运维命令行工具：https://github.com/eyjian/redis-tools/tree/master

批量操作工具：: https://github.com/eyjian/libmooon/releases

5.Redis Cluster专业术语

6.Redis Cluster集群数据共享

Redis集群使用数据分片而非一致性哈希来实现：一个redis集群包含16384个哈希槽，数据库中的每个键都属于这16384个哈希槽的其中一个，集群使用公式CRC16(key) % 16384来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和。

• 节点A负责0号至5500号哈希槽。
• 节点B负责处理5501号至11000号哈希槽。
• 节点C负责处理11001号至16384号哈希槽

哈希槽的计算公式：

集群使用公式CRC16(key) & 16383 计算键key属于哪个槽。

7.Redis Cluster集群运行机制

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

为了使得集群在一部分节点下线或者无法与集群的大多数节点进行通讯的情况下，仍然可以正常运作，redis集群对节点使用了主从复制功能：集群中的每个节点都有1个至N个复制品，其中一个复制品为主节点，而其余的N-1个复制品为从节点。

• 在之前列举的节点A,B,C的例子中，如果节点B下线了，那么集群将无法正常运行，因为集群找不到节点来处理5501-11000号哈希槽。
• 假如在创建集群的时候（或者至少在节点B下线之前），我们为主节点B添加了从节点B1，那么当主节点B下线的时候，集群就会将B1设置为新的主节点，并让它代替下线的主节点B，继续处理5501-11000号哈希槽，这样集群就不会因为主节点B的下线而无法运作了。
• 不过如果节点B和B1都下线的话，redis集群还是会停止运作。
• 集群的复制特性中用了slaveof命令的代码，所以集群节点的复制行为和slaveof命令的复制行为完全相同。

8.Redis Cluster集群的故障转移

1. 在集群里面，节点会对其他节点进行下线检测。
2. 当一个节点下线时，集群里面的其他主节点负责对下线主节点进行故障转移。
3. 换句话说，集群的节点集成了下线检测和故障转移等类似Sentinel的功能。
4. 因为Sentinel是一个独立运行的监控程序，而集群的下线检测和故障转移等功能是集成在节点里面的，它们的运行模式非常的不同，所以尽管这两者的功能很相似，但集群的事先没有重用Sentinel的代码。

8.1 redis cluster集群里面执行命令的两种情况

①命令发送到了正确的节点

命令要处理的键所在的槽正好是由接收命令的节点负责，那么该节点执行命令，就像单机redis服务器一样。

槽位说明：

• 7000：槽0-5000
• 7001：槽5001-10000
• 7002：槽10001-16383

键date位于2022槽，该槽由节点7000负责，命令会直接执行。

②命令发送到了错误的节点

接收到命令的节点并非处理键所在槽的节点，那么节点将向客户端返回一个转向错误，告知客户端应该到哪个节点去执行这个命令，客户端会根据错误提示的信息，重新向正确的节点发送命令。

键date位于2022槽，该槽由节点7000负责，但错误发送到了7001节点，7001向客户返回专项错误

客户端根据转向错误的指引，转向到节点7000，并重新发送命令

9.Redis Cluster集群关于转向错误

在集群中的节点会互相告知对方，自己负责处理哪些槽。

集群中的每个节点都会记录16384个槽分别由哪个节点负责，从而形成一个“槽表”（slot table）。

节点在接收到命令请求时，会通过槽表检查键所在的槽是否由本节点处理：

• 如果是的话，那么节点直接执行命令；
• 如果不是的话，那么节点就从槽表里面提取出正确节点的地址信息，然后返回转向错误。

10.Redis Cluster集群部署配置

redis cluster要求至少三主三从共6各节点才能组成redis集群，测试环境可一台物理机上启动6个redis节点，但生产环境至少要准备3台物理机或者虚拟机。

#创建实例
cd /etc/redis/
mkdir -p redis-cluster/redis700{0..5}

for w in {0..5}
do
cp /opt/redis-5.0.7/redis.conf  /etc/redis/redis-cluster/redis700$w
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis700$w
done

#开启集群功能
其他5个文件夹的配置文件以此类推修改，注意6个端口都要不一样。
vim /etc/redis/redis-cluster/redis6000/redis.conf

#bind 127.0.0.1                       #69行，注释掉bind项，默认监听所有网卡
protected-mode no                     #88行，修改，关闭保护模式
port 7000                             #92行，修改，redis 监听端口,
daemonize yes                         #136行，开启守护进程，以独立进程启动
appendonly yes                        #700行，修改，开启AOF持久化
cluster -enabled yes                  #832行，取消注释，开启群集功能
cluster-config-file nodes-6379.conf   #840行，取消注释，群集名称文件设置
cluster-node-timeout 15000            #846行，取消注释群集超时时间设置

#启动redis节点
#分别进入那六个文件夹，执行命令: redis-server redis.conf，来启动redis节点
cd /etc/redis/redis-cluster/redis6000
./redis-server ./redis.conf

#(或使用for循环来启动）
for i in {0..5}
do
cd /etc/redis/redis-cluster/redis600$i
./redis-server ./redis.conf
done

#启动集群
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
#加-c参数，节点之间就可以互相跳转
redis-cli -p 6000 -c     
#查看节点的哈希槽编号范围
cluster slots			     

11.Redis Cluster操作命令行

1、集群cluster

CLUSTER INFO  打印集群的信息
CLUSTER NODES 列出集群当前已知的所有节点（node) ，以及这些节点的相关信息。

2、节点node

CLUSTER MEET <ip> <port> 将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。
CLUSTER FORGET <node_id>从集群中移除node_id指定的节点。
CLUSTER REPLICATE <node id> 将当前节点设置为 node id 指定的节点的从节点
CLUSTER SAVECONFIG将节点的配置文件保存到硬盘里面。

3、槽slot

CLUSTER ADDSLOTS <slot> [slot … ] 将一个或多个槽(slot/指派(assign/ 结当即节点。
CLUSTER DELSLOTS <slot> [slot … ] 移除一个或多个槽对当前节点的指派。
CLUSTER FLUSHSLOTS 移除指派给当前节点的所有让 变成一个没有指派任何槽的节点
CLUSTER SETSLOT <slot> NODE <node_id> slot 指派给 node_id 指定的节点，如果槽已经指派给另一个节点，那么先让另一个节点删除该槽>，然后再进行指派。
CLUSTER SETSLOT <slot> MIGRATING <node_id> 将本节点的橹 slot 迁移到 node_id 指定的节点中。
CLUSTER SETSLOT <slot> IMPORTING <node_id> 从 node_id 指定的节点中导入槽 slot 到本节点。
CLUSTER SETSLOT <slot> STABLE取消槽slot 的导入 (import 或者讦移（miarate) 

4、键key

CLUSTER KEYSLOT <key> 计算键 key 应该被放置在哪个槽上。
CLUSTER COUNTKEYSINSIOT <slot> 返回槽slot目前包含的键值对数量
CLUSTER GETKEYSINSLOT <slot> ccount> 返回 count 个 slot 槽中的键

END