redis主从复制

  实际开发过程中,一个redis服务器往往不够,一是因为当服务器发生故障时不能及时恢复服务,二是因为所有的请求都由一台服务器来处理,压力太大。
  
  redis主从复制的原理如下:
  
  image_1b6te1ne83gt8tv16fk1q5cslgm.png-94.3kB
  
  如上图所示,我们可以将一台redis服务器作为主库,多台其他的服务器作为从库,主库只负责写数据,从库负责读数据,当主库数据更新时,会同步到它所有的从库。这就实现了主从复制,读写分离。既可以解决服务器负载过大的问题,又能够在一台服务器发生故障时及时使用其他服务器恢复数据。
  
  下面演示一下redis中的主从复制,首先我们创建三份配置文件,分别对应端口号6379,6380,6381开启三个redis服务:
  
  image_1b6tkng1fiu31u751qtaifju9v4b.png-488.3kB
  
  由于我们现在没有配置主从库,所以可以通过命令info replication看到,三台服务器都分别是独立的主库。现在我们将端口号6379配置为主库(master),将端口号6380和6381配置为6379的从库,配置方法为在从库中执行命令:

SLAVEOF 主库IP地址 主库端口号

  如下图所示,我们先在6379中设置一些key,然后将6380和6381配置为其从库,然后发现可以在从库中读取主库中的数据:
  
  image_1b6tft2hui2h1h2p3kg7ij1fdc1t.png-270.6kB
  
  默认情况下,从库只能读取数据,执行写操作会报错:
  
  image_1b6tg1g4enp6m2i1fumk5dssa2a.png-299.9kB
  
  但是,可以在从库对应的配置文件中进行配置:(yes为只读,不可写)
  
  image_1b6tg30vv1uv31dhj1ht31kkoh1s2n.png-4.2kB
  
  然而,通常情况下从库中修改的数据不会被同步到任何其他数据库,但是一旦主库中修改了数据,从库的数据会被自动同步覆盖,所以一般情况下,不建议将从库设置为可写。
  
  在从库中可以通过执行如下命令来放弃和原主库的同步,而与新主库建立同步:

SLAVEOF 新主库IP地址 新主库端口号

  另外,在从库中可以通过执行命令:

SLAVEOF NO ONE

  从而将从库升级为独立的主库:
  
  image_1b6tg97knm3of951glau2b1bhm34.png-375.5kB
  
  如果主库宕机,从库会“原地待命”,待主库重新连接之后,会恢复和主库的联系:
  
  image_1b6tgrope15sv1cnj1hkelhvvth3h.png-160.2kB
  
  image_1b6tgtr2a1pn9odb1u80nqc1vp83u.png-253kB
  
  但是,如果从库宕机,连接会断开,当从库重新连接自后,需要重新建立与主库的连接:
  
  image_1b6th1v4lho243r1ij338i1gb94o.png-140kB
  
  一个库可以是一个库的从库,同时也可以是另一个库的主库,这样可以有效减轻master的压力,避免所有的从库都从一个主库中读取数据:
  
  image_1b6thadfe1is31fu21aapjnv1mh89.png-88.1kB
  
  关系演变过程如下图所示:
  
  image_1b6thibrm1l2qk2v1f9umlv1ckgm.png-233.4kB
  
  哨兵模式:
  哨兵模式是通过后台监控主库是否故障,当主库发生故障时,将根据投票数自动将某一从库转换为主库。
  下面演示启动哨兵模式的步骤:
  首先创建文件sentinel.conf,目录自行选择,我选择在redis配置文件同目录下创建:
  
  image_1b6tic9c912v7kuhk2b6a91qbk1g.png-50.4kB
  
  配置哨兵文件,配置格式为:

sentinel monitor 被监控的数据库名字(自行定义) 被监控数据库的IP地址 被监控数据库服务的端口号 票数

  其中票数n表示,得票数超过n的从库被升级为主库。现在,我们将哨兵文件配置为:
  
  image_1b6tiq88tsqk12io1pvn18ku16h21t.png-32.4kB
  
  保存退出后执行如下命令启动哨兵:

redis-sentinel /etc/redis/sentinel.conf

  其中/etc/redis/sentinel.conf是我刚刚配置的哨兵文件的路径,执行命令后,我们可以看到哨兵开始监视主库6379:
  
  image_1b6tj5c8h1bj4rkaqq6mjsb9o2a.png-143.1kB
  
  现在,我们让主库宕机:
  
  image_1b6tj9lbu12hh1nr98cg2an1lku2n.png-60kB
  
  可以看到哨兵开始组织投票,并且决定让6380成为新的主库:
  
  image_1b6tjdu17ev4hq91ri516dgqpc3h.png-209kB
  
  image_1b6tjco9t1t2p1k4t6ot1jeqncf34.png-132.8kB
  
  现在,如果原先的主库6379重新连接,它会成为新主库6380的从库:
  
  image_1b6tjk1mle1k14ma195f3021oha3u.png-172.6kB
  
  
  主从复制的原理:
  主库master和从库slave的复制分为全量复制和增量复制:
  全量复制:全量复制一般发生在slave初始化阶段,此时slave需要将master上的所有数据都复制一份,具体步骤如下:
  1. 从库连接到主库,并发送一条SYNC命令;
  2. 主库接收到SYNC命令后,开始执行BGSAVE命令生成RDB快照文件,并使用缓冲区记录此后执行的所有写命令;
  3. 主库执行完BGSAVE之后,将快照文件发送到所有从库,在此期间,仍继续将所有写命令记录到缓冲区;
  4. 从库在接收到快照文件后,丢弃所有旧数据,载入快照文件中的新数据;
  5. 主库继续向从库发送缓冲区中的写命令;
  6. 从库将快照文件中的数据载入完毕后,继续接收主库发送的缓冲区中的写命令,并执行这些写命令以更新数据。
  完成上面的步骤之后,从库可以开始接收来自用户的读数据请求。

  增量复制:增量复制是指,在slave初始化完成后的工作阶段,主库将新发生的写命令同步到从库的过程。主库每执行一条写命令,都会向从库发送相同的写命令,从库会执行这些写命令。
  总结:主库和从库初次建立连接时,进行全量复制;全量复制结束后,进行增量复制。但是当增量复制不成功时,需要发起全量复制。
    

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值