Redis主从复制的配置并进行场景测试

为什么要使用主从复制？

Redis虽然读写的速度相对于传统的关系型数据库较快，但是也会出现读取压力比较大的情况，为了避免出现这种情况的发生，以免给用户造成不好的体验，这时候就要考虑Redis的主从复制了。所谓主从复制，就是一个master下有多个slave节点。用户对于数据的操作，都是读远远大于写的，所以我们只在master节点下进行写的操作，而读就交给slave节点，这样就很好的分摊压力，保证Redis的读写性能。
在Redis中，数据的复制都是单向的，只能从Master节点复制到Salve节点。而一个Salve节点只能有一个Master节点。

主从复制的作用：

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
崩溃恢复：当Master节点出现错误时，从节点会担当重任，来保证数据的读写操作可正常进行，快速的实现故障修复。
负载均衡：在主从复制的基础上，配合使用读写分离，可以由主节点实现写操作，从节点提供读操作，分担服务器的压力。尤其是读多写少的情况下，通过多个Salve节点分担读操作，可以极大的提高Redis的并发量。

我们可以在Master节点写配置多个Salve节点，而Salve节点下依然可以配置多个Salve节点。

手动配置实现一主多从：

虽然通过命令行我们也可以对从节点进行配置，但是一旦宕机配置就会失效，所以我这里采用的是配置文件进行配置。

配置文件进行配置（以一台服务器配置多个redis.conf文件达到一主多从的目标为例）：
打开redis.conf配置文件我们可以找到REPLICATION节点。只需配置从节点的配置文件即可，Master节点不需要操作。

slaveof <masterip> <masterport>    #salveof master节点IP master节点端口
masterauth <master-password>       #如果master节点有密码，需要在此配上密码
slave-serve-stale-data yes         #主从复制中，从服务器可以响应客户端请求
slave-read-only yes                #从节点只读，不可写
repl-diskless-sync no              #默认不使用diskless同步方式
repl-diskless-sync-delay 5         #无磁盘diskless方式在进行数据传递之前会有
一个时间的延迟，以便slave端能够进行到待传送的目标队列中，这个时间默认是5秒
repl-timeout 60                    #设置超时时间

在配置之前我们先通过命令查看一下6379Master节点是否存在Salve节点：

127.0.0.1:6379> info replication
# Replication
role:master               #该节点为Master节点
connected_slaves:0        #没有从节点
master_replid:26dda30d25e234451caf414978532d5a1a55b257
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>

如果我们想把该Redis6380变成某一个Redis6379的Salve节点，那么需要修改slaveof Redis6379的IP Redis6379的端口号，除此之外还有port、pidfile、logfile、dbfilename这四个地方需要更改以免和Master节点冲突（针对在一台服务器配置多个redis.conf文件来实现一主多从的方式需要修改port、pidfile、logfile、dbfilename）如果有Master节点有密码那么还需要修改masterauth Redis6379的密码
完成以上两个配置，Redis6380就变成了Redis6379的从节点。
配置文件修改完毕之后我们查看一下进程是否都正常启动：

我们可以看到6379和6380以及6381端口都正常启动了。
那我们再来看下此时6380节点的信息：

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:8aba049a5b9bcec45ad5afa87fa5c7f682189d40
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42
127.0.0.1:6380>

我们可以看到，6380的role是Slave，他的Master节点的IP为127.0.0.1 端口号为6379等一些Master的信息。同样的在6381节点看到的也和6380看到的一样。那此时Master节点的信息会变成什么样呢？我们来看一下。

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=364,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=364,lag=1
master_replid:8aba049a5b9bcec45ad5afa87fa5c7f682189d40
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:364
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:364
127.0.0.1:6379>

在Master节点中我们可以看到他下面的两个Salve节点的信息。

场景测试

既然主从复制已经配置好了，那我们不妨测试几个场景：

场景一：在Master节点插入数据，看在两个Salve节点是否能查询的到
场景二：6380节点突然宕掉，这时Master节点还在插入数据，重新启动6380，看能否查到宕机期间Master插入的数据。
场景三：Master突然宕机，两个Salve节点是否能正常查询。

场景一测试结果：

#在Master6379节点插入一条数据
127.0.0.1:6379> set name Silence
OK
127.0.0.1:6379> get name
"Silence"
127.0.0.1:6379>

#6380Salve节点可以获取到Master节点插入的数据
127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380>

#6381Salve节点可以获取到Master节点插入的数据
127.0.0.1:6381> get name
"Silence"
127.0.0.1:6381>

由此可以看出，我们在Master节点插入的数据在两个Salve节点是可以查询到的。

场景二测试结果：
我们把6380Salve节点的进程kill掉，然后在Master节点插入数据。

[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:02 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6307     1  0 16:37 ?        00:00:01 redis-server 127.0.0.1:6380
root      6315  6283  0 16:37 pts/1    00:00:00 redis-cli -p 6380
root      6343     1  0 16:41 ?        00:00:01 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6403  6382  0 17:00 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# kill 6307
[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:02 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6315  6283  0 16:37 pts/1    00:00:00 redis-cli -p 6380
root      6343     1  0 16:41 ?        00:00:01 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6405  6382  0 17:00 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]#

6380Salve节点的服务已经被kill掉。
在Master节点插入数据：
这是Master和两个Salve节点查询数据的状态是这样的：

127.0.0.1:6379> set name Silence
OK
127.0.0.1:6379> get name
"Silence"
127.0.0.1:6379> set name wen
OK
127.0.0.1:6379> get name
"wen"
127.0.0.1:6379> #6380Salve节点
127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380> get name
Could not connect to Redis at 127.0.0.1:6380: Connection refused
not connected> #6381Salve节点
127.0.0.1:6381> get name
"Silence"
127.0.0.1:6381> get name
"wen"
127.0.0.1:6381>

分析执行结果可以看到，Master和6381Salve节点都是可以正常获取到插入的数据，而6380是获取不到的。那么现在我们重新启动一下6380节点，并获取数据看能否获取到宕机期间Master插入的数据。

127.0.0.1:6380> get name
"Silence"
127.0.0.1:6380> get name
Could not connect to Redis at 127.0.0.1:6380: Connection refused
not connected> exit
[root@Silence bin]# redis-server redis6380.conf
[root@Silence bin]# redis-cli -p 6380
127.0.0.1:6380> get name
"wen"
127.0.0.1:6380>

咦？在6380宕机期间Master插入的数据在6380恢复服务之后竟然还可以查到，由此可见主从复制是多么的牛X！

场景三测试结果：
我们把Master节点给kill掉。

[root@Silence /]# ps -ef|grep redis
root      6254  6208  0 16:32 pts/2    00:00:03 redis-server 127.0.0.1:6379
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:02 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:00 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6431  6382  0 17:08 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]# kill 6254
[root@Silence /]# ps -ef|grep redis
root      6280  6261  0 16:33 pts/0    00:00:00 redis-cli
root      6343     1  0 16:41 ?        00:00:02 redis-server 127.0.0.1:6381
root      6351  6323  0 16:41 pts/3    00:00:00 redis-cli -p 6381
root      6422     1  0 17:05 ?        00:00:00 redis-server 127.0.0.1:6380
root      6427  6283  0 17:06 pts/1    00:00:00 redis-cli -p 6380
root      6433  6382  0 17:08 pts/4    00:00:00 grep --color=auto redis
[root@Silence /]#

这时候再去两个Salve节点查询数据。

#6380Salve节点依然可以查询的到之前Master节点插入的数据
127.0.0.1:6380> get name
"wen"#6381Salve节点也依然可以查询的到之前Master节点插入的数据
127.0.0.1:6381> get name
"wen"

虽然两个Salve节点仍然可以查到Master节点之前插入的数据，但是用户有新数据插入的话两个Salve节点可以插入数据吗？
答案是不可以，不信的话我们可以来试试

127.0.0.1:6380> set age 23
(error) READONLY You can't write against a read only replica.
127.0.0.1:6380> 127.0.0.1:6381> set age 25
(error) READONLY You can't write against a read only replica.
127.0.0.1:6381>

根据结果可以看出，两个Salve节点是无法插入数据的。

那么问题就来了，当Master突然宕机了，写入操作该怎么办？请看下篇文章。