Redis：10.主从复制

阅读量

1.主从复制

1.1.概念：

  • 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；
  • 数据的复制是单向的，只能由主节点到从节点。
  • Master以写为主，Slave 以读为主。

主从复制，读写分离！80%的情况下都是进行读操作，用于减缓服务器的压力，架构中经常使用。至少要保证一主二从，在公司中，主从复制是必须要使用的。

默认情况下，每台Redis服务器都是主节点。且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 （一个父亲可有多个儿子，儿子只有一个父亲）

1.2.主从复制的主要作用：

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

1.3.一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：

  1. 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。服务器宕机就凉凉了。
  2. 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存。一般来说，单台Redis最大使用内存不应该超过20G（超过了就要考虑集群）。
    电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。对于这种场景，我们可以使如下这种架构：
    加载图片！

1.3.查看当前库信息： 

1
2
3
4
5
6
7
8
9
10
11
12
127.0.0.1:6379> info replication   # 查看当前库的信息
# Replication
role:master  					   # 角色：master表示是主机
connected_slaves:0 				   # 从机个数
master_replid:b63c90e6c501143759cb0e7f450bd1eb0c70882a
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

2.集群环境配置

只需配置从库，不用配置主库。(因为Reedis默认自己就是主库，所以要通过配置文件，让其变为从库)
1.复制3份配置文件，用作从机的配置文件。 

1
2
3
4
5
6
7
8
# 服务器配置文件 我复制到了myconfig目录下
cd myconfig/
cp redis.conf redis79.conf
cp redis.conf redis80.conf
cp redis.conf redis81.conf

ls
redis.conf redis79.conf redis80.conf redis81.conf

2.修改配置文件（以redis80.conf为例）
因为在一台服务器上运行多个Redis服务端，为了使他们之间端口号以及生成的文件不出现冲突，所以要修改每个配置文件的以下内容。（这里只是为了测试方便，正常情况下是多机多服务） 

1
2
3
4
5
port 6380      # 修改端口号
daemonize yes  # 打开后台运行
pidfile /var/run/redis_6380.pid  # 存储pid的文件
logfile "6380.log"     # 日志文件
dbfilename dump80.rdb  # 库文件

3.分别在不同的终端里启动Redis（以redis80.conf为例） 

1
2
3
4
redis-server myconfig/redis80.conf

# 启动完三个Redis后。可通过下列命令查看进程信息。
ps -ef|grep redis

4.分别在不同的终端里，用客户端连接Redis服务器（以redis80.conf对应的服务器为例）

1
redis-cli -p 6380

5.主一从二配置

默认情况下，每台Redis服务器都是主节点。

所以一般情况下，只用配置从机就可以。

真实开发中，主从配置应该在配置文件中配置，这样的话是永久的，这里使用的是命令，只是暂时的！
如何配置从机？ - 认爹。
说明：一主（79），二从（80，81）
从机配置（以redis81.conf为例） 

1
2
3
4
5
6
7
8
9
10
11
12
# slaveof host port
127.0.0.1:6381> slaveof 127.0.0.1 6379  # 认爹

# 查看当前库的信息
127.0.0.1:6381> info replication  
# Replication
role:slave  	       # 角色：slave表示是从机
master_host:127.0.0.1  # 主机地址 
master_port:6379       # 主机端口号
.
.
.

查看主机信息： 

1
2
3
4
5
6
7
8
9
10
11
12
13
127.0.0.1:6379> info replication  # 查看当前库的信息
# Replication
role:master
connected_slaves:2         #多了两个从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=210,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=210,lag=1
master_replid:3cfc9f3aa664a35ec4130b6baf1529bb7523b822
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:210
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1

修改配置文件进行配置

真实开发中的配置方式：修改从机的redis.conf配置文件。 

1
2
3
4
5
6
7
# 配置主机ip和端口
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379

# 如果主机有密码，则还需配置密码
# masterauth <master-password>
masterauth 123456

3.主从复制细节 - 读写分离

  1. 主机可以写，从机不能写只能读。（主机中的所有信息和数据，都会自动被从机保存）
  2. 当主机断开连接，从机依旧连接到主机，但是没有写操作，如果主机回来了，从机依旧可以直接获取到主机写的信息。
  3. 当从机断开连接，主机进行了写操作，此时从机再连接回来，从机还是可以读取到断开这段时间主机写的信息。
  4. 如果是使用命令行来配置主从的话，主机重启之后依然是主机。但是从机重启之后不再是从机，需要从新配置，一旦变回从机，依旧可以从主机中获取信息。（因为默认情况下，每台Redis服务器都是主机）

4.从机复制原理

Slave 启动成功连接到 master后会发送一个sync同步命令。
Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步。
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！ (我们的数据一定可以在从机中看到！)

链表式主从复制：
上一个主节点 连接下一个从节点。也能完成主从复制。
但是中间哪个节点崩了，它后面的所有从机就都无效了。
加载图片！

上面的命令行配置，与链式配置，在工作中都不会使用。

5.哨兵模式

如果主机挂了，那么谁来当爹呢？

  • 手动配置（在从机中选一个当爹，并进行配置）
  • 哨兵模式！（不用手动配置的，自动选举爹模式）

概述

  1. 主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。
  2. 谋权篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
  3. 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
    加载图片！

这里的哨兵有两个作用：

  1. 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
  2. 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服
    务器，修改配置文件，让它们切换主机。

多哨兵模式：
一个哨兵进程对Redis服务器进行监控，如果这个哨兵挂了，可能会出现问题。为此，可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。（类似于Eureka集群）

加载图片！

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。

当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，这时可以认为主服务器不可用了。那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作（票数高的作为新的主机）。切换主机成功后，就会通过发布订阅模式，让各个哨兵把自己监控的 从服务器 实现切换主机，这个过程称为客观下线。

测试哨兵

1、哨兵程序位置
加载图片！

2、哨兵程序配置
我们现在目前的状态是一主（6379）二从（6380、6381）。 因此哨兵也可以选择3个 。

分别给6379、6380、6381配置一个sentinel.conf。即sentinel26379.conf、sentinel26380.conf、sentinel26381.conf。

这里以sentinel26380.conf为例进行配置：
1、我们到刚刚复制的redis.conf目录下（myconfig）新建一个sentinel26380.conf文件。
配置如下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
port 26379       # 哨兵端口
daemonize yes    # 守护态运行
logfile "26379.log"  # 日志文件
dir "./"         # 哨兵工作目录
bind 127.0.0.1   # 绑定ip 多个ip使用空格隔开

# 告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效（由于我们有3个哨兵，这里可填2）
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。如果没有密码，可以不写。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒,单位毫秒
# sentinel down-after-milliseconds <master-name> <milliseconds> 
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves> 
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
# 1.同一个sentinel对同一个master两次failover之间的间隔时间。
# 2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。  
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟,单位毫秒
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout 180000
```  


此时，哨兵模式配置完毕，此外还可以再配置文件里配置一些额外信息如： 
```bash
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），
#将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信
#息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配
#置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无
#法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已
# 经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配置

3、启动哨兵
配置完毕之后，分别启动sentinel。 

1
2
3
4
# 在Redis目录下 分别执行以下命令
redis-sentinel myconfig/sentinel23679.conf
redis-sentinel myconfig/sentinel23680.conf
redis-sentinel myconfig/sentinel23681.conf

4、测试
关闭主机Master（模拟主机故障）， 这时候就会从从机中随机选择一个服务器！（这里有一个投票算法） 

1
2
127.0.0.1:6379> shutdown
not connected> exit

查看6381库信息 ： 

1
2
3
4
5
127.0.0.1:6381> info replication
# Replication
role:master #成为新的主机
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=14507,lag=1

查看6380库信息 ： 

1
2
3
4
5
127.0.0.1:6380> info replication
# Replication
role:slave #从机
master_host:127.0.0.1
master_port:6381  #主机变成了6381

如果主机此时回来了，只能归并到新的主机下，老老实实当儿子，做从机，这就是哨兵模式的规则。

5、 哨兵模式的优缺点
优点：

  1. 哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。
  2. 主从可以切换，故障可以转移，系统的可用性就会更好。
  3. 哨兵模式就是主从模式的升级，手动到自动。

缺点：

  1. Redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦。
  2. 实现哨兵模式的配置其实是麻烦的，里面有很多选择。

更多可以参考博客

赏

失败是成功之母

支付宝
微信

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

JAVA<br><br>学习永不止步<br>简简单单