Redis (三)_代码007

本文介绍: 配置过的从机是只能执行读操作，不能执行写操作，这样以来可以实现读写分离提高性能。#从机写入假设主机启动后然后执行了多次的写操作后从机才启动，那么从机可以读取之前的写入的数据嘛，是这样的从机第一次启动的话会备份主机的之前的所有的数据做到同步，然后对于后续的主机的写操作同步的更新。#主机写OKOK#启动从机，访问数据正常> get k2v2> get k3v3主机宕机的话会出现什么操作，是从机变主机？数据读取失败？是这样的从机还是老老实实的做从机，等待主机恢复，而且读取数据正常没有影响。

1、redis复制

简单的概括就是主从复制，master以写为主，Slave以读为主，当master数据发生变化的时候，自动将更新的数据异步同步到其他的slave是数据库。

使用这种机制的话，可以做到读写分离，可以减轻主机负担。使用这种方式的话可以容灾恢复，就是如果主机挂掉了。还有其他的数据备份，而且数据也是实时的。所以宕机的时候多啦保证！数据备份以及水平扩容支持高并发。

配置从库不配置主库，对于权限信息，如果master配置了密码，需要密码才可以登录，那么slave就需要配置masterauth来设置校验的密码，否则的话master就会拒绝slave的访问请求。

1.1、相关命令

使用info replication
1. 可以查看复制节点的主从关系和配置信息
replicaof 主库ip 主库端口
1. 配置在从机的配置文件中，配置主机的数据
slaveof 主库ip 主库端口
1. 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
2. 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据库的同步关系，转而和新的主数据库同步
slaveof no one
1. 使当前数据库停止与其他数据库的同步，转成主数据库，自立为王

1.2、配置

一个master，然后两个slave，也讲就是说，需要三台虚拟机然而且每一个虚拟机上都安装redis，当然这只是基础的配置条件，然后接下来就是实现这种模式的具体配置。注意要给关闭每一个虚拟机的防火墙。

开启daemonize

daemonize yes

修改ip

bind 192.168.200.88 -::1

protected-mode

protected-mode no

指定端口

port 6379

指定当前的工作目录

dir /software/redis/redis-7.2.3/redisconf/backupfiles

pid文件名字，pidfile

pidfile /var/run/redis_6379.pid

log文件名字

logfile /software/redis/redislog/redis-log.log

本机密码

requirepass 123456

dump.rdb文件名字

dbfilename dump88.rdb

aof文件，appendfilename

暂时不开启

主机密码

replicaof 192.168.200.88 6379
masterauth "10100109"

1.2.1、主从复制

三台linux虚拟机，然后安装配置完成后正常启动连接！

查看主机日志文件如下

26152:M 04 Jan 2024 17:57:06.501 * Synchronization with replica 192.168.200.111:6380 succeeded
26152:M 04 Jan 2024 17:59:59.525 * Replica 192.168.200.99:6380 asks for synchronization
26152:M 04 Jan 2024 17:59:59.525 * Full resync requested by replica 192.168.200.99:6380
26152:M 04 Jan 2024 17:59:59.525 * Delay next BGSAVE for diskless SYNC

26152:M 04 Jan 2024 18:00:04.517 * Synchronization with replica 192.168.200.99:6380 succeeded
26152:M 04 Jan 2024 18:04:57.044 * Connection with replica 192.168.200.111:6380 lost.
26152:M 04 Jan 2024 18:05:12.186 * Replica 192.168.200.111:6381 asks for synchronization
26152:M 04 Jan 2024 18:05:12.187 * Partial resynchronization request from 192.168.200.111:6381 accepted. Sending 14 bytes of backlog starting from offset 673.

查看从机日志

6107:S 04 Jan 2024 18:05:12.189 * Ready to accept connections tcp
6107:S 04 Jan 2024 18:05:12.190 * Connecting to MASTER 192.168.200.88:6379
6107:S 04 Jan 2024 18:05:12.190 * MASTER <-> REPLICA sync started
6107:S 04 Jan 2024 18:05:12.190 * Non blocking connect for SYNC fired the event.
6107:S 04 Jan 2024 18:05:12.191 * Master replied to PING, replication can continue...

主机查看配置info replication

> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.200.99,port=6380,state=online,offset=1624,lag=0
slave1:ip=192.168.200.111,port=6381,state=online,offset=1624,lag=0
master_failover_state:no-failover
master_replid:ad3197cb5b7476962c1243102b7a135a8cfe83d5
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1624
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1624

从机查看配置，info replication

> info replication
# Replication
role:slave
master_host:192.168.200.88
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_read_repl_offset:1820
slave_repl_offset:1820
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:ad3197cb5b7476962c1243102b7a135a8cfe83d5
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1820
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:267
repl_backlog_histlen:1554

测试

#主机
> set k1 v1
OK

#从机
> get k1
v1

> get k1
v1

1.2.1.1、总结

配置过的从机是只能执行读操作，不能执行写操作，这样以来可以实现读写分离提高性能。

#从机写入
> set k2 v2
READONLY You can't write against a read only replica.

假设主机启动后然后执行了多次的写操作后从机才启动，那么从机可以读取之前的写入的数据嘛，是这样的从机第一次启动的话会备份主机的之前的所有的数据做到同步，然后对于后续的主机的写操作同步的更新。

#主机写
> Linux-master-redis connected!
> set k2 v2
OK
> set k3 v3
OK

#启动从机，访问数据正常
> linux-111-6381 connected!
> get k2
v2
> get k3
v3

主机宕机的话会出现什么操作，是从机变主机？数据读取失败？是这样的从机还是老老实实的做从机，等待主机恢复，而且读取数据正常没有影响。

#主机宕机
shutdown

#从机读写
> get k1
v1
> set k4 v4
READONLY You can't write against a read only replica.

主机重启不影响之前建立的关系

#主机
> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.200.111,port=6381,state=online,offset=10316,lag=1
slave1:ip=192.168.200.99,port=6380,state=online,offset=10316,lag=0
master_failover_state:no-failover
master_replid:0fc82d3e3251195aec8a42cc1b350b54a5435054
master_replid2:ad3197cb5b7476962c1243102b7a135a8cfe83d5
master_repl_offset:10316
second_repl_offset:10289
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:10289
repl_backlog_histlen:28
> set k4 v4
OK

#从机读取
> get k4
v4

欧克，上面是使用配置文件的方式来使用，也就是写死的这种情况，但是我们还有可以使用命令的方式来进行配置，接下来停掉两个从机，然后注释掉之前的配置文件，然后测试不同的情况。

# replicaof 192.168.200.88 6379

重启后查看主从配置

#三台都是主机!
> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:c69b05376562297a6868fc0311814cb9d0233331
master_replid2:0fc82d3e3251195aec8a42cc1b350b54a5435054
master_repl_offset:12174
second_repl_offset:12175
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:12175
repl_backlog_histlen:0

好滴，指定主机使用命令，发现连接以后数据同步！

#从机执行
SLAVEOF 192.168.200.88 6379

测试关机后的从机，重启后使用主从关系命令设置后，关系失效，也就是说使用命令的方式的话是临时的，只有使用配置文件的话是可以永久生效的。

1.2.2、叠叠乐

这个不看也大致可以猜出来就是，一个主机的从机可以是另外一个从机的主机！也就是说即使是从机也可以接受其他的从机的连接以及数据同步，这样的话可以分担主机的写压力！为了方便演示就不在使用配置文件了，采用命令的方式使用比较方便。

#主机
192.168.200.88 

#从机 ————主机
192.168.200.99

#从机
192.168.200.111

#欧克当我连接完毕后发现数据已经同步完成，接下来测试不同的情况

#主机写看从机的从机的数据同步
> set k5 v5
OK

> SLAVEOF 192.168.200.88 6379
OK
> get k5
v5

> SLAVEOF 192.168.200.99  6380
OK
> get k5
v5

#对于从机的从机来讲，从机也是主机（哈哈哈），那么他可以写嘛
> set k6 v6
READONLY You can't write against a read only replica.


#主机挂了，从机的从机可以写嘛，不可以，但是可以读！
> linux-99-6380 connected!
> get k1
v1
> set k6 v6
READONLY You can't write against a read only replica.

1.2.3、自立门户

使用命令可以，然当前的redis服务器脱离主从关系，变为主机。

> linux-111-6381 connected!
> SLAVEOF no one
OK
> set k6 v6
OK

1.3、总结

1.3.1、工作模式

slave启动成功连接master后会发送一个同步的命令，然后对于初次连接的话，slave会将master中的数据全部复制copy，做到数据的同步，然后salve自身原有的数据会被master数据覆盖清除。

首次连接、全量复制

master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)，同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步，而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化。

心跳持续、保持通信

master发出PING包的周期，默认是10秒

repl-ping-replica-period 10

进入平稳、增量复制

Master继续将新的所有收集到的修改命令自动依次传给slave，完成同步。

从机下线，重连续传

master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId，offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave，类似断点续传。

1.3.2、缺点

复制延时，信号衰减，大概的意思就是，要满足高可用的方式工作的话，需要在一个主机上挂载很多的从机，数据在同步的时候会有演示，从机越多问题越明显。

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

主机挂掉，从机还是只能读，直到主机重启。（无人值守—哨兵）

2、哨兵模式

哨兵模式就是可以监控redis的运行状态呢，然后如果主机发生了故障会根据投票数自动将某一个从库转换成为新的主库，然后对外提供服务。不在需要人工的干预。

2.1、哨兵模式功能

主从监控：可以监控主机和从机的运行状态是不是正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果master异常，那么会进行主从的切换，将其中的一个slave作为新的master
配置中心：客户端通过连接哨兵来获得当前的redis服务的主节点的地址

2.2、哨兵模式架构

首先要说明为什么要用哨兵的集群（奇数防止投票数一样的情况。）呐，第一点就是，只配置一个哨兵，那么哨兵挂掉后，然后主机也挂掉，那么整个哨兵模式就白搭了。所以配置集群可以避免这中情况，第二点就是防止专断，就是如果主机只是因为网络延时导致哨兵判断失误，然后将当前的主机判定为挂掉重新选举主机，多台可以投票判断（民主方式）。

2.2.1、配置方式

上面是我们的redis.conf文件，然后就是按照上面的架构模式配置的话，要配置六台虚拟机，直接把电脑撑爆，太离谱没钱加装内存条！首先不建议直接在原配置文件上修改，所以还是和之前一样将原配置文件复制到指定的文件夹然后配置。

[root@localhost redis-7.2.3]# cp sentinel.conf /software/redis/redis-7.2.3/redisconf/sentinel.conf

除了配置和配置redis.conf的基础配置项之外，还要配置额外的如下配置

首先在sentinel.conf配置参数，除了配置主从复制的参数之外，然后还有加上监视的主机的信息

sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 192.168.111.169 6379 2
设置要监控的master服务器，quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。

quorum：确认客观下线的最少的哨兵数量，只有哨兵的投票数大于这个最小的数量的时候才会确认这个主机挂掉了，我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

配置监视主机的密码，master设置了密码，连接master服务的密码

sentinel auth-pass <master-name> <password>     
sentinel auth-pass mymaster 111111

指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel down-after-milliseconds <master-name> <milliseconds>

配置表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

sentinel parallel-syncs <master-name> <nums>

故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel failover-timeout <master-name> <milliseconds>

配置当某一事件发生时所需要执行的脚本

sentinel notification-script <master-name> <script-path>

客户端重新配置主节点参数脚本

sentinel client-reconfig-script <master-name> <script-path>

样板:

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

#主机以及哨兵
root      22727      1  0 22:23 ?        00:00:00 redis-server 192.168.200.88:6379
root      26236      1  1 22:26 ?        00:00:00 redis-sentinel 192.168.200.88:26379 [sentinel]

#从机以及哨兵
[root@localhost sentinel]# ps -ef|grep redis|grep -v grep
root      22745      1  0 22:23 ?        00:00:00 redis-server 192.168.200.99:6379
root      26484      1  0 22:26 ?        00:00:00 redis-sentinel 192.168.200.99:26379 [sentinel]

[root@jiangyiqing sentinel]# ps -ef|grep redis|grep -v grep
root      22486      1  0 22:23 ?        00:00:00 redis-server 192.168.200.111:6379
root      26571      1  1 22:26 ?        00:00:00 redis-sentinel 192.168.200.111:26379 [sentinel]

条件有限只能这样演示数据！

查看哨兵日志，发现一切正常你，三个哨兵构成集群。

#启动后测试主从正常，然后测试主机挂掉，然后使用命令哪一个从机会成为主机

#首先查看数据没有问题
> get k1
v1

#然后随机挑选从机查看状态是不是选举出来新的主机
> info replication
# Replication
role:slave
master_host:192.168.200.99
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:250240
slave_repl_offset:250240
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:85db2fa7fc5bf6864636b8a376da63f06e4ea4e3
master_replid2:e43a6c37a2ce62bdf26cbff3113e9b735518c7fe
master_repl_offset:250240
second_repl_offset:250076
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:477
repl_backlog_histlen:249764

#发现主机的ip已经跟换，然后说明配置的哨兵模式起作用

#测试在新选举的主机上写操作
> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.200.111,port=6379,state=online,offset=295068,lag=1
master_failover_state:no-failover
master_replid:85db2fa7fc5bf6864636b8a376da63f06e4ea4e3
master_replid2:e43a6c37a2ce62bdf26cbff3113e9b735518c7fe
master_repl_offset:295209
second_repl_offset:250076
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:218877
repl_backlog_histlen:76333
> set k2 v2
OK

#测试从机读取
> get k2
v2

#测试之前挂掉的主机重启后，谁是master
> info replication
# Replication
role:slave
master_host:192.168.200.99
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_read_repl_offset:252218
slave_repl_offset:252218
master_link_down_since_seconds:-1
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:fefb137f28d435ed43656ac31e88e94e66be09c6
master_replid2:e43a6c37a2ce62bdf26cbff3113e9b735518c7fe
master_repl_offset:252218
second_repl_offset:250076
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:250076
repl_backlog_histlen:2143
#很明显之前的主机启动后并没有成为master而是成为slave，但是不知道为什么，刚刚用新产生的master做了一次写操作，然后另外的从机可以读取，但是对于刚启动的挂掉的主机却读取不到数据！！

> get k2
null

测试挂掉的烧饼日志

2.3、工作流程

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

首先按照配置好的redis的哨兵框架，哨兵正常的监视着主机的状态，但是突然有一天…

2.3.1、SDown主观下线

所谓主观下线（Subjectively Down，简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息，那么这个Sentinel会主观的(单方面的)认为这个master不可以用了，o(╥﹏╥)o

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据，master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

那么多哨兵就你一个说不行就不行，肯定是不可以的！

2.3.2、ODown客观下线

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉。( 民主决议，少数服从多数！），这里就使用到了quorum参数，投个票吧，然后看赞同宕机的有多少，如果大于quorum参数就可以认主机宕机啦，意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

好好好，也知道主机是宕机啦，那要选出一个主机吧，那么多兵，你说这个，我说那个！难搞

2.3.3、哨兵兵王

当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点，也即被选举出的兵王进行failover（故障迁移）。怎么说，谁是兵王，投个票吧！

选出领导者使用的是Raft算法！监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：

即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

欧克，兵王有啦，该解决问题了叭

2.3.4、故障迁移

2.3.4.1、新主登基

兵王选出来一个slave成为master，好嘛，有什么规则嘛，别不明不白的就选了！

redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )
复制偏移位置offset最大的从节点，就是谁的数据更接近master的数据
最小Run ID的从节点，字典顺序ASCII码

2.3.4.2、群臣俯首

执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点，Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点。Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave。