精华内容
下载资源
问答
  • 在前面的一篇博客中【Redis多实例及主从复制环境搭建】简单的介绍了一下redis主从复制原理以及搭建redis主从复制环境, Redis的复制是基于rdb方式的持久化实...


    在前面的一篇博客中【Redis多实例及主从复制环境搭建】简单的介绍了一下redis的主从复制原理以及搭建redis的主从复制环境,


          Redis的复制是基于rdb方式的持久化实现的,即主数据库端在后台保存rdb快照,从数据库端则接受并载入快照文件、这样的实现优点是可以显著的简化逻辑,复用已有的代码,但是缺点也是非常明显的:

    (1)当主数据库禁用rdb快照时[删除配置文件中的save语句],如果执行了复制初始化的操作,redis依然会生成rdb快照,所以下次启动后主数据库会以该快照恢复数据。因为复制发生的时间不能确定,这使得恢复数据可能是任何的时间点的。

    (2)因为复制初始化的时候需要在硬盘中创建rdb快照文件,所以如果硬盘的性能很慢时,这一过程会对性能产生影响。举个例子来说,当使用redis做缓存系统时,因为可能不需要持久化,所以服务器的硬盘读写速度可能较差。但是当该缓存系统使用一主多从的架构时,每次和从数据库与同步,redis都会执行一次快照,同时对硬盘进行读写,导致性能降低。

    因此,从redis2.8.18版本开始,redis引入了无硬盘复制选项,开启该选项时,redis在与从数据库进行复制初始化时将不会将快照内容存储到硬盘上,而是直接通过网络的发送给数据库,有效的避免了性能的瓶颈问题。

    可以在配置文件中使用如下的参数配置来开启该功能:

    repl-diskless-sync yes

     

    一、全量复制

    全量复制的过程:

    1、从服务器向主服务器发送PSYNC命令,携带主服务器的runid和复制偏移量;第一次的话,slave不知道master 的 runid,所以是?,偏移量是-1

    2、主服务器验证runid和自身runid是否一致,如不一致,则进行全量复制;

    3、Master把自己的runid和offset(偏移量)发给slave

    4、Slave将master的runid和offset进行保存

    5、Master进行bgsave,生成RDB文件

    6、在生成RDB文件的过程中,如果master再有写操作,会将写操作放入repl_back_buffer缓冲区

    7、将写好的RDB文件传递给slave,将缓冲区内的数据传送给slave

    8、Salve清楚原来的数据,加载RDB和缓冲区数据

     

    全量复制的开销包括以下几个方面:

    1、bgsave时间

    2、RDB文件网络传输时间

    3、从节点清空数据时间

    4、从节点加载RDB数据时间


     

    二、增量复制

     

    接下来重点说一下增量复制,了解了全量复制后,我们会出现这样的一个疑问:

    当主从数据库连接断开后,从数据库会发送SYNC命令来重新进行一次完整复制操作。【提示:redis 2.8版本之后从数据库会向主数据库发送PSYNC命令来代替SYNC以实现增量复制】这样即使主从断开期间数据库的变化很小,甚至没有,也需要将数据库中的所有数据重新快照并传送一次。在正常的网络应用环境中,这种实现方式显然不是很理想。Redis 2.8版本的重要更新之一就是主从断线重连的情况下的增量复制。

     

    增量复制是基于下面三点实现的:

    (1)从数据库会存储主数据库的运行id[run id]。每一个redis实例运行都会有一个唯一的运行id,每当实例重新启动后,就会重新生成一个新的运行id。

    (2)在复制同步阶段,主数据库每将一个命令传送给从数据库时,都会同时把该命令存放在一个积压队列中(backlog),并记录下当前积压队列中存放命令的的偏移量。

    (3)同时,从数据库接受到主数据库传来的命令时,会影响该命令的偏移量。

    以上的3点是实现增量复制的基础。如上所述,当主从连接准备就绪后,从数据库会发送一条SYNC命令来告诉主数据库可以开始把所有数据同步过来,而2.8版本后,不在发送SYNC命令,取而代之的是PSYNC,格式为“PSYNC 主数据库的运行id 断开前最新的命令偏移量”。当主数据库收到PSYNC命令后,会执行以下的判断来决定此次重连是否可以执行增量复制:

    (1)首先,主数据库会判断从数据库传来的运行id是否和自己的运行id相同、这一步骤的意义在于确保从数据库之前确实是和自己同步的,以避免从数据库拿到错误的数据[比如主数据库在断开期间重启过,会造成数据的不一致]。

    (2)然后判断从数据库最后同步成功的命令的偏移量是否在积压队列中,如果在则可以执行增量复制,并将积压队列中的相应的命令发送给从数据库。如果此次重连不满足增量复制的条件,主数据库会进行一次全部同步。

     

    下面简单的解释一下什么是积压队列:

    积压队列在本质上是一个固定长度的循环队列,默认情况下积压队列的大小为1M,可以通过配置文件中的repl-backlog-size参数来调整大小。很容易理解的是,积压队列越大,其允许的主从数据库断线的时间就越长。根据主从数据库之间的网络状态,设置一个合理的积压队列很重要。因为积压队列存储的的内容是命令本身,如:set name wjq,所以估算积压队列的大小只需要估计主从数据库断线的时间中主数据库可能执行的命令大小即可。

    与积压队列相关的另一个配置选项使repl-backlog-ttl,即当所有从数据库与主数据库断开连接后,经过多久时间可以释放积压队列的内存空间。默认是1小时[3600s];

     

     

     

    我们可以看到主节点记录了从节点的偏移量信息。


     
    关于redis主从复制环境搭建可参考:Redis多实例及主从复制环境搭建http://blog.itpub.net/31015730/viewspace-2155578/

    下面配置文件redis.conf中关于主从复制的一些配置参数进行了解释说明:


    关于redis配置文件的参数介绍可参考:redis配置文件中各参数详解http://blog.itpub.net/31015730/viewspace-2154818/

    ################################# REPLICATION #################################

    # 将当前节点设置为运行在机器127.0.0.1上的6379端口实例的从节点  

    # slaveof <masterip> <masterport>  

    slaveof 127.0.0.1 6379  

      

    # 主节点设置验证密码,从节点在进行复制请求时,需要通过auth进行验证  

    # masterauth <master-password>  

    masterauth qcloud@2018  

      

    # 从节点和主节点失去连接或者从节点正处于复制数据过程中,从节点响应客户端的方式  

    # “yes” 从节点使用旧数据响应客户端请求  

    no从节点给客户端反馈一个错误信息"SYNC with master in progress"  

    slave-serve-stale-data yes  

      

    # 从Redis 2.6开始 从节点默认只读模式。有时可以将从节点配置为可写模式,但是只能存储临时的数据,因为主从同步会很快删除这些临时数据。  

    # 同时注意从节点不能暴露给不安全的网络环境下  

    slave-read-only yes  

      

      

    # 从机器会每隔10秒钟 向主发送ping命令 以保住主节点活着  

    # repl-ping-slave-period 10  

      

    # 这是个响应超时的时间,需要从两个角度来看  

    # 从的角度来看,批量传输数据、从ping主等  

    # 主的角度来看,REPLCONF ACK pings等   

    # 这个值一定要大于repl-ping-slave-period 这个值  

    # repl-timeout 60  

      

      

    # 若配置为yes,则禁用NO_DELAY,则TCP协议栈会合并小包统一发送,这样可以减少主从节点间的包数量并节省带宽,但会增加数据同步到slave的时间。  

    # 若配置为no,表明启用NO_DELAY,则TCP协议栈不会延迟小包的发送时机,这样数据同步的延时会减少,但需要更大的带宽。  

    # 通常情况下,应该配置为no以降低同步延时,但在主从节点间网络负载已经很高的情况下,可以配置为yes。  

    repl-disable-tcp-nodelay no  

      

      

    # 主节点的复制缓冲区大小,默认是1M,根据实际情况可以调大这个数值  

    # repl-backlog-size 1mb  

      

    # 当主失去所有从节点时,默认经过3600秒回释放复制缓冲区中的值  

    # 当设置为0时,意味着从不释放  

    # repl-backlog-ttl 3600  

      

    #Redis哨兵Sentinel会根据slave的优先级选举一个master。最低的优先级的slave,当选master。  

    #而配置成0,永远不会被选举。默认为100  

    slave-priority 100  

      

    #表示只有当3个(或以上)的从库连接到主库时,主库才是可写的,否则会返回错误  

    # min-slaves-to-write 3  

     

    #表示允许从库最长失去连接的时间,如果从库最后与主库联系(即发送“replconf  ack”命令)的时间小于这个值,则认为从库还在保持与主库的连接。  

    # min-slaves-max-lag 10  

     

     

     更多关于redis的相关知识可参考:http://blog.itpub.net/31015730/cid-185228-list-1/


    Redis 4.0集群环境部署http://blog.itpub.net/31015730/viewspace-2155989/




    作者:SEian.G(苦练七十二变,笑对八十一难)

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31015730/viewspace-2156282/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/31015730/viewspace-2156282/

    展开全文
  • Redis主从复制原理及配置这里写自定义目录标题写在前面1. 复制原理2.配置3. 读写分离4. 主服务器只在有至少 N 个从服务器的情况下,才执行写操作 写在前面 Redis 支持简单且易用的主从复制(master-slave ...

    写在前面

    Redis 支持简单且易用的主从复制(master-slave replication)功能, 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。

    1. 复制原理

    Redis的主从复制主要分为以下几个步骤:

    1. 当建立一个从服务器时, 从服务器都将向主服务器发送一个 SYNC 命令
    2. 主服务器接收到SYNC命令之后开始执行 BGSAVE , 并在保存操作执行期间, 将所有新执行的写入命令都保存到一个缓冲区里面
    3. 当 BGSAVE 执行完毕后, 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器, 从服务器接收这个 .rdb 文件, 并将文件中的数据载入到内存中。
    4. 之后主服务器会以 Redis 命令协议的格式, 将写命令缓冲区中积累的所有内容都发送给从服务器

    主从复制的基本原理

    2.配置

    Redis的复制遵循的基本原理是:配从不配主
    在从服务器的配置文件中设置

    slaveof  ipAddress  port
    

    当然,也可以用以下在从服务器中用以下命令。

    slaveof  ipAddress  port
    

    3. 读写分离

    所谓的读写分离指的是:主服务器写,从服务器只读。
    在从服务器的redis.conf文件中配置

    slave-read-only yes
    

    4. 主服务器只在有至少 N 个从服务器的情况下,才执行写操作

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

    以下是这个特性的运作原理:

    • 从服务器以每秒一次的频率 PING 主服务器一次, 并报告复制流的处理情况。
    • 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
    • 用户可以通过配置, 指定网络延迟的最大值 min-slaves-max-lag , 以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。

    如果至少有 min-slaves-to-write 个从服务器, 并且这些服务器的延迟值都少于 min-slaves-max-lag 秒, 那么主服务器就会执行客户端请求的写操作。

    你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: 尽管不能保证写操作的持久性, 但起码丢失数据的窗口会被严格限制在指定的秒数中。

    可以在redis配置文件中配上如下命令

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

    5 复制机制实战模式

    全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。

    增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步

    但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

    本机中建立三个redis的服务器

    端口 端口号 主从
    port 6379
    port 6380
    port 6381

    需要修改的配置文件

    appendfilename "appendonly6379.aof"
    
    dbfilename dump6379.rdb
    
    logfile "6379.log"
    
    pidfile /var/run/redis_6380.pid
    

    5.1 查看节点的配置信息

    info replication
    

    具体的信息:

    # Replication
    role:master
    connected_slaves:0
    master_replid:98cc791f79ec72ed8e954d939c4a32bf6f253107
    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
    

    5.2 设置从机的节点信息

    默认情况下只配置从机的跟随信息
    从库配置:slaveof 主库IP 主库端口

    SLAVEOF 127.0.0.1 6379
    

    一旦连接上主机,从机 会备份主机所有的信息

    注意点:

    1. 从机只允许读不允许写
    127.0.0.1:6380> set k6 v6
    (error) READONLY You can't write against a read only replica.
    
    1. 主机挂了,从机如何做?

    从机还会原地等待,直到主机重新连接,一旦主机重新连接会继续承担主机责任。

    1. 从机挂了,一旦从机重新连接会如何?

    从机会与主机断开连接,称为另一个主机,如果还是需要与原主机形成主从关系,还是需要重新建立起关联,除非配入了配置文件中。

    127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
    OK Already connected to specified master
    
    1. 主机挂了,从机如何成为主机?
      从机可以通过如下命令成为主机:
      SLAVEOF no one使当前数据库停止与其他数据库同步,转成主数据库
    127.0.0.1:6380> SLAVEOF no one
    OK
    

    然后通过新的连接建立起主从关系

    127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
    OK
    

    5.3 哨兵模式

    一旦master挂了,自动从slaver中选择一个服务器作为master。

    反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。

    example:

    1. 一主二从
    2. 新建sentinel.conf文件
    3. 配置哨兵,填写内容。
    sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
    
    sentinel monitoer host6379 127.0.0.1 6379 1
    

    最后数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机
    4. 启动哨兵

    /usr/local/var/db/redis/sentinel.confsentinel的文件地址

    redis-sentinel /usr/local/var/db/redis/sentinel.conf
    

    启动之后的内容:

    redis redis-sentinel /usr/local/var/db/redis/sentinel.conf
    10279:X 20 Feb 2020 19:54:46.057 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    10279:X 20 Feb 2020 19:54:46.058 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=10279, just started
    10279:X 20 Feb 2020 19:54:46.058 # Configuration loaded
    10279:X 20 Feb 2020 19:54:46.059 * Increased maximum number of open files to 10032 (it was originally set to 4864).
                    _._
               _.-``__ ''-._
          _.-``    `.  `_.  ''-._           Redis 5.0.5 (00000000/0) 64 bit
      .-`` .-```.  ```\/    _.,_ ''-._
     (    '      ,       .-`  | `,    )     Running in sentinel mode
     |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
     |    `-._   `._    /     _.-'    |     PID: 10279
      `-._    `-._  `-./  _.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |           http://redis.io
      `-._    `-._`-.__.-'_.-'    _.-'
     |`-._`-._    `-.__.-'    _.-'_.-'|
     |    `-._`-._        _.-'_.-'    |
      `-._    `-._`-.__.-'_.-'    _.-'
          `-._    `-.__.-'    _.-'
              `-._        _.-'
                  `-.__.-'
    
    10279:X 20 Feb 2020 19:54:46.061 # Sentinel ID is 170869946001af78516f578cf651d7854b7b1766
    10279:X 20 Feb 2020 19:54:46.061 # +monitor master host6379 127.0.0.1 6379 quorum 1
    10279:X 20 Feb 2020 19:54:46.065 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:54:46.066 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
    

    可以看到sentinel后台选举的日志:

    10279:X 20 Feb 2020 19:57:53.519 # +sdown master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.519 # +odown master host6379 127.0.0.1 6379 #quorum 1/1
    10279:X 20 Feb 2020 19:57:53.519 # +new-epoch 1
    10279:X 20 Feb 2020 19:57:53.519 # +try-failover master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.522 # +vote-for-leader 170869946001af78516f578cf651d7854b7b1766 1
    10279:X 20 Feb 2020 19:57:53.522 # +elected-leader master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.522 # +failover-state-select-slave master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.598 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.598 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.673 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.845 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.845 # +failover-state-reconf-slaves master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:53.898 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:54.876 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:54.876 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:54.978 # +failover-end master host6379 127.0.0.1 6379
    10279:X 20 Feb 2020 19:57:54.978 # +switch-master host6379 127.0.0.1 6379 127.0.0.1 6380
    10279:X 20 Feb 2020 19:57:54.979 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6380           // 选举6380作为master
    10279:X 20 Feb 2020 19:57:54.979 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ host6379 127.0.0.1 6380           // 选举6380作为master
    

    一旦选举了新的master之后,即使原来挂掉的master正常连接,会成为slaver

    可以看到如下两个slaver

    127.0.0.1:6380> info replication
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=127.0.0.1,port=6381,state=online,offset=32172,lag=0       // 6381作为slaver
    slave1:ip=127.0.0.1,port=6379,state=online,offset=32172,lag=0       // 6379作为slaver
    master_replid:561e44624ae1f8b195f0ac001f036290894974cf
    master_replid2:9aa285e0ed5f95030ef8b4722fcd4feda0a578b8
    master_repl_offset:32172
    second_repl_offset:11329
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:1
    repl_backlog_histlen:32172
    

    reference:
    [1]: http://doc.redisfans.com/topic/replication.html

    展开全文
  • 前言2.Redis集群方案比较3.Redis伪主从搭建(1主2从)4.Redis主从复制原理5.结语 1.前言 博主最早接触的是redis高可用集群(linux+windows),因为当时在国网,有充足的硬件支持,也写过搭建博文,但并不是所...

    Redis主从架构搭建以及主从复制原理

    每天多学一点点~
    话不多说,这就开始吧…

    1.前言

    博主最早接触的是redis高可用集群(linux+windows),因为当时在国网,有充足的硬件支持,也写过搭建博文,但并不是所有公司都有那么多服务器,最近有时间重新整理一下redis的三种集群模式~今天先搭建redis主从架构

    Redis系列文章

    2.Redis集群方案比较

    1. 主从模式
      在这里插入图片描述
      最初的redis架构模式,主写从读,为了防止服务器挂了(硬盘坏了)的情况下数据丢失,且不存在选举,若主服务器挂了,必须重写启动从服务器,改其配置让其成为主(当然可以写脚本,虽然现在基本上不怎么用了),但是其主从之间的复制原理还是很重要的,后文会介绍。
    2. 哨兵模式
      在这里插入图片描述在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态,如果master节点异常,则会 做主从切换,将某一台slave作为master,哨兵的配置略微复杂,并且性能和高可用性等各方面表现一般,特别是在主从切换的瞬间存在访问瞬断的情况,而且哨兵模式只有一个主节点对外提供服务,没法支持很高的并发,且单个主节点内存也不宜设置得过大,否则会导致持久化文件过大,影响数据恢复或主从同步的效率
    3. 高可用集群
      在这里插入图片描述
      Redis集群是一个由多个主从节点群组成的分布式服务器群,它具有复制、高可用和分片特性。Redis集群不需要 sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式,这种集群模式没有中心节点,可 水平扩展,据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于 之前版本的哨兵模式,且集群配置非常简单

    3.Redis伪主从搭建(1主2从)

    搭建方式和真正主从一模一样,只是放在了一台虚拟机上而已,且只有一个redis-server而已。
    192.168.73.130:6380(主) 192.168.73.130:6381(从) 192.168.73.130:6382(从)
    建立三个文件夹 6380 6381 6382,将redis.conf文件复制到其中

    1. 修改一下配置(对应到各个端口)
    port 6380    # redis端口
    daemonize yes  #后台启动
    bind 0.0.0.0       #让其他ip的客户端可以连接(不然本机连不上虚拟机)
    pidfile /var/run/redis_6380.pid  #redis进程文件id
    logfile "6380.log" 					#redis日志文件
    dir /usr/local/redis5.0.2/zhucong/data/6380   # redis日志文件目录
    
    1. 在两个从节点redis.conf文件上配置主从复制
    replicaof 192.168.73.130  6380 	# 从本机6380的redis实例复制数据
    replica-read-only yes              	   # 让从节点只读
    
    1. 启动节点(以配置文件形式启动)
      先启动主节点
    src/redis-server /usr/local/redis5.0.2/zhucong/6380/redis.conf 
    

    在这里插入图片描述
    再启动从节点

    src/redis-server /usr/local/redis5.0.2/zhucong/6381/redis.conf   #6381
    src/redis-server /usr/local/redis5.0.2/zhucong/6382/redis.conf   #6382
    

    在这里插入图片描述
    查看主从架构信息

    info replication #
    

    在这里插入图片描述
    测试主从是否搭建成功

    1. 在6380(主)上写数据,看是否同步到从节点
    redis-cli -p 6380  #连接redis
    set name zjq      #设置
    redis-cli -p 6381
     scan 0 match * count 10     #用游标查找
    

    在这里插入图片描述
    在这里插入图片描述

    1. 在从上写数据,看是否拒绝
      在这里插入图片描述
      主从架构搭建成功(主写,从读)

    4.Redis主从复制原理

    1. 如果你为master配置了一个slave,不管这个slave是否是第一次连接上Master,它都会发送一个SYNC命令(redis2.8版本之前的命令)给master请求复制数据。
    2. master收到SYNC命令后,会在后台进行数据持久化通过bgsave生成最新的rdb快照文件,持久化期间, master会继续接收客户端的请求,它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后,master会把这份rdb文件数据集发送给slave,slave会把接收到的数据进行持久化生成rdb,然后再加载到内存中。然后,master再将之前缓存在内存中的命令发送给slave。
    3. 当master与slave之间的连接由于某些原因而断开时,slave能够自动重连Master,如果master收到了多个slave并发连接请求,它只会进行一次持久化,而不是一个连接一次,然后再把这一份持久化的数据发送 给多个并发连接的slave。 当master和slave断开重连后,一般都会对整份数据进行复制。但从redis2.8版本开始,master和slave断开重连后支持部分复制

    数据部分复制

    从2.8版本开始,slave与master能够在网络连接断开重连后只进行部分数据复制。 master会在其内存中创建一个复制数据用的缓存队列,缓存最近一段时间的数据,master和它所有的 slave都维护了复制的数据下标offset和master的进程id,因此,当网络连接断开后,slave会请求master 继续进行未完成的复制,从所记录的数据下标开始。如果master进程id变化了,或者从节点数据下标offset太旧,已经不在master的缓存队列里了,那么将会进行一次全量数据的复制。 从2.8版本开始,redis改用可以支持部分数据复制的命令PSYNC去master同步数据
    主从复制(全量复制)流程图:
    主从复制(全量复制)流程图
    主从复制(部分复制)流程图:
    主从复制(部分复制)流程图

    5.结语

    世上无难事,只怕有心人,每天积累一点点,fighting!!!

    展开全文
  • Redis主从集群搭建及容灾部署哨兵sentinel Redis主从集群搭建及容灾部署 哨兵sentinel 目录 1. Redis安装 2. Redis主从结构搭建 3. Redis容灾部署哨兵sentinel 4. Redis常见问题 5. 参考 redis安装 1.1. liunx环境...
  • Redis多副本(主从); Redis Sentinel(主从 + 哨兵); Redis Cluster; 主从同步基础概念 互联网系统一般是以主从架构为基础的,所谓主从架构设计的思路大概是: 在多台数据服务器中,只有一台主服务器,而主...

    Redis的几种常见高可用使用方式包括:

    • Redis多副本(主从);
    • Redis Sentinel(主从 + 哨兵);
    • Redis Cluster;

    主从同步基础概念

    互联网系统一般是以主从架构为基础的,所谓主从架构设计的思路大概是:

    • 在多台数据服务器中,只有一台主服务器,而主服务器只负责写入数据,不负责让外部程序读取数据。
    • 存在多台从服务器,从服务器不写入数据,只负责同步主服务器的数据,并让外部程序读取数据。
    • 主服务器在写入数据后,即刻将写入数据的命令发送给从服务器,从而使得主从数据同步。
    • 应用程序可以随机读取某一台从服务器的数据,这样就分摊了读数据的压力。
    • 当从服务器不能工作的时候,整个系统将不受影响;当主服务器不能工作的时候,可以方便地从从服务器中选举一台来当主服务器。

    请注意上面的思路,笔者用了“大概”这两个字,因为这只是一种大概的思路,每一种数据存储的软件都会根据其自身的特点对上面的这几点思路加以改造,但是万变不离其宗,只要理解了这几点就很好理解 Redis 的复制机制了。主从同步机制如图 1 所示。

    主从同步机制

    图 1  主从同步机制

    这个时候读数据就可以随机从服务器上读取,当从服务器是多台的时候,那么单台服务器的压力就大大降低了,这十分有利于系统性能的提高,当主服务器出现不能工作的情况时,也可以切换为其中的一台从服务器继续让系统稳定运行,所以也有利于系统运行的安全性。当然由于 Redis 自身具备的特点,所以其也有实现主从同步的特殊方式。

    Redis 主从同步配置

    对 Redis 进行主从同步的配置分为主机与从机,主机是一台,而从机可以是多台。
    首先,明确主机。当你能确定哪台机子是主机的时候,关键的两个配置是 dir 和 dbfilename 选项,当然必须保证这两个文件是可写的。对于 Redis 的默认配置而言,dir 的默认值为“./”,而对于 dbfilename 的默认值为“dump.rbd”。换句话说,默认采用 Redis 当前目录的 dump.rbd 文件进行同步。对于主机而言,只要了解这多信息,很简单。
    其次,在明确了从机之后,进行进一步配置所要关注的只有 slaveof 这个配置选项,它的配置格式是:

    slaveof server port

    其中,server 代表主机,port 代表端口。当从机 Redis 服务重启时,就会同步对应主机的数据了。当不想让从机继续复制主机的数据时,可以在从机的 Redis 命令客户端发送 slaveof no one 命令,这样从机就不会再接收主服务器的数据更新了。又或者原来主服务器已经无法工作了,而你可能需要去复制新的主机,这个时候执行 slaveof sever port 就能让从机复制另外一台主机的数据了。
    在实际的 Linux 环境中,配置文件 redis.conf 中还有一个 bind 的配置,默认为 127.0.0.1,也就是只允许本机访问,把它修改为 bind 0.0.0.0,其他的服务器就能够访问了。
    上面的文字描述了如何配置,但是有时候需要进一步了解 Redis 主从复制的过程,这些内容对于复制而言是很有必要的,同时也是很有趣的。

    Redis 主从同步的过程原理

    Redis 主从同步的过程如图 2 所示。

    Redis主从同步

    图 2  Redis 主从同步


    图 2 中左边的流程是主服务器,而右边的流程为从服务器,这里有必要进行更深层次的描述:
    1)无论如何要先保证主服务器的开启,开启主服务器后,从服务器通过命令或者重启配置项可以同步到主服务器。
    2)当从服务器启动时,读取同步的配置,根据配置决定是否使用当前数据响应客户端,然后发送 SYNC 命令。
    当主服务器接收到同步命令的时候,就会执行 bgsave 命令备份数据,但是主服务器并不会拒绝客户端的读/写,而是将来自客户端的写命令写入缓冲区。从服务器未收到主服务器备份的快照文件的时候,会根据其配置决定使用现有数据响应客户端或者拒绝。
    3)当 bgsave 命令被主服务器执行完后,开始向从服务器发送备份文件,这个时候从服务器就会丢弃所有现有的数据,开始载入发送的快照文件。
    4)当主服务器发送完备份文件后,从服务器就会执行这些写入命令。此时就会把 bgsave 执行之后的缓存区内的写命令也发送给从服务器,从服务完成备份文件解析,就开始像往常一样,接收命令,等待命令写入。
    5)缓冲区的命令发送完成后,当主服务器执行一条写命令后,就同时往从服务器发送同步写入命令,从服务器就和主服务器保持一致了。而此时当从服务器完成主服务器发送的缓冲区命令后,就开始等待主服务器的命令了。
    以上 5 步就是 Redis 主从同步的过程。
    只是在主服务器同步到从服务器的过程中,需要备份文件,所以在配置的时候一般需要预留一些内存空间给主服务器,用以腾出空间执行备份命令。一般来说主服务器使用 50%~65% 的内存空间,以为主从复制留下可用的内存空间。
    多从机同步机制,如图 3 所示。

    多从机同步机制

    图 3  多从机同步机制

    如果出现多台同步,可能会出现频繁等待和频繁操作 bgsave 命令的情况,导致主机在较长时间里性能不佳,这个时候我们会考虑主从链进行同步的机制,以减少这种可能。

    主从复制(Replication-Sentinel模式)

    搭建

    安装Redis

    $ yum-y install gcc $ yum -y install gcc-c++
    $ wget http://download.redis.io/releases/redis-5.0.4.tar.gz 
    $ tar -zvxf redis-5.0.4.tar.gz 
    $ cd redis-5.0.4 
    $ make
    

    这里我们将redis.conf文件复制两份slave.conf和slave2.conf并修改配置

    # 服务器端口号,主从分别修改为7001 7002 7003 
    port 7001 
    # 使得Redis可以跨网络访问 
    bind 0.0.0.0 
    # 配置reids的密码 
    requirepass "111111" 
    # 下面两个配置只需要配置从节点(slave) 
    # 配置主服务器地址、端口号 
    replicaof 127.0.0.1 7001 
    # 主服务器密码 
    masterauth "111111"

    分别启动这三个Redis服务

    $./src/redis-server redis.conf 
    $ ./src/redis-server slave.conf 
    $ ./src/redis-server slave2.conf
    

    使用redis-cli工具连接redis服务查看主从节点是否搭建成功

    $./src/redis-cli -h <主机名> -p <端口号> 
    $ auth <password> 
    $ info replication
    

    看到类似如下所示信息则主从搭建成功

    ############主节点(master)信息#############
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=192.168.1.164,port=7002,state=online,offset=1015511,lag=0
    slave1:ip=192.168.1.164,port=7003,state=online,offset=1015511,lag=0
    master_replid:ffff866d17e11dcc9a9fd7bf3a487ad9e499fca9
    master_replid2:1c8a6f05891dc72bbe4fefd9a54ff65eb46ce35d
    master_repl_offset:1015511
    second_repl_offset:424773
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:99239
    repl_backlog_histlen:916273
    ############从节点(slave)信息#############
    # Replication
    role:slave
    master_host:192.168.1.164
    master_port:7001
    master_link_status:up
    master_last_io_seconds_ago:0
    master_sync_in_progress:0
    slave_repl_offset:560709
    slave_priority:100
    slave_read_only:1
    connected_slaves:0
    master_replid:ffff866d17e11dcc9a9fd7bf3a487ad9e499fca9
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:560709
    second_repl_offset:-1
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:549628
    repl_backlog_histlen:11082

    工作原理-Sentinel

    简单的主从集群有个问题,就是主节点挂了之后,无法从新选举新的节点作为主节点进行写操作,导致服务不可用。所以接下来介绍Sentinel(哨兵)功能的使用。哨兵是一个独立的进程,哨兵会实时监控master节点的状态,当master不可用时会从slave节点中选出一个作为新的master,并修改其他节点的配置指向到新的master。

    该系统执行以下三个任务:

    • 监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
    • 提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
    • 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

    搭建步骤

    新开一台服务器,并按上面的步骤下载安装Redis。

    将sentinel.conf文件复制两份为sentinel2.conf、sentinel3.conf,并分别修改配置

    # 三个配置文件分别配置不同的端口号
    port <端口号>
    # 设置为后台启动
    daemonize yes
    # 主节点的名称(可以自定义,与后面的配置保持一致即可)
    # 主机地址
    # 端口号
    # 数量(2代表只有两个或两个以上的哨兵认为主服务器不可用的时候,才会进行failover操作)
    sentinel monitor mymaster 127.0.0.1 6379 2
    # 多长时间没有响应认为主观下线(SDOWN)
    sentinel down-after-milliseconds mymaster 60000
    # 表示如果15秒后,mysater仍没活过来,则启动failover,从剩下从节点序曲新的主节点
    sentinel failover-timeout mymaster 15000
    # 指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长
    sentinel parallel-syncs mymaster 1

    启动三个sentinel

    $./src/server-sentinel sentinel.conf 
    $ ./src/server-sentinel sentinel2.conf 
    $ ./src/server-sentinel sentinel3.conf
    

    然后手动关闭主节点的redis服务,并查看两个slave信息是否有一个变成了master。

    程序中使用

    SpringBoot连接Redis主从集群配置

    spring:
      redis:
        sentinel:
          master: mymaster
          nodes: 192.168.1.167:26379,192.168.1.167:26380,192.168.1.167:26381
        host: 192.168.1.164
        port: 7003
        database: 0
        password: <password>
    

    参考文档http://www.redis.cn/topics/replication.htmlhttp://www.redis.cn/topics/sentinel.html

    Redis集群(Redis-Cluster)

    工作原理

    Redis 集群是一个提供在多个Redis节点间共享数据的程序集。下图以三个master节点和三个slave节点作为示例。Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽,如图中slots所示。

    为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有1-n个从节点。例如master-A节点不可用了,集群便会选举slave-A节点作为新的主节点继续服务。

    搭建步骤

    Redis5.0之后的版本放弃了 Ruby 的集群方式,改为使用 C 语言编写的redis-cli的方式,使集群的构建方式复杂度大大降低。

    下载安装Redis(见主从复制模式的搭建步骤)。

    创建6个Redis的配置文件,如下所示:

    /usr/local/redis-5.0.4/redis-cluster-conf/7001/redis.conf
    /usr/local/redis-5.0.4/redis-cluster-conf/7002/redis.conf
    /usr/local/redis-5.0.4/redis-cluster-conf/7003/redis.conf
    /usr/local/redis-5.0.4/redis-cluster-conf/7004/redis.conf
    /usr/local/redis-5.0.4/redis-cluster-conf/7005/redis.conf
    /usr/local/redis-5.0.4/redis-cluster-conf/7006/redis.conf

    配置文件内容:

    port7001  # 端口,每个配置文件不同7001-7006
    cluster-enabled yes # 启用集群模式
    cluster-config-file nodes.conf #节点配置文件
    cluster-node-timeout 5000 # 超时时间
    appendonly yes # 打开aof持久化
    daemonize yes # 后台运行
    protected-mode no # 非保护模式
    pidfile  /var/run/redis_7001.pid # 根据端口修改
    

    启动6个Redis节点。

    ./src/redis-server redis-cluster-conf/7001/redis.conf
    ./src/redis-server redis-cluster-conf/7002/redis.conf
    ./src/redis-server redis-cluster-conf/7003/redis.conf
    ./src/redis-server redis-cluster-conf/7004/redis.conf
    ./src/redis-server redis-cluster-conf/7005/redis.conf
    ./src/redis-server redis-cluster-conf/7006/redis.conf

    此时启动的6个Redis服务是相互独立运行的,通过以下命令配置集群。

    ./src/redis-cli --cluster create --cluster-replicas 1 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 127.0.0.1:7006

    配置完看到如下图所示信息表示集群搭建成功:

    从图中可以看到启动了3个master节点,3个slave节点,16384个槽点平均分配到了3个master节点上。图中很长的一串字母数字的组合(07000b3a90......)为节点的ID。后面对节点的操作中会用到。

    集群重新分片

    如果对默认的平均分配不满意,我们可以对集群进行重新分片。执行如下命令,只需要指定集群中的其中一个节点地址即可,它会自动找到集群中的其他节点。(如果设置了密码则需要加上 -a <password>,没有密码则不需要,后面的命令我会省略这个,设置了密码的自己加上就好)。

    ./src/redis-cli -a<password> --cluster reshard 127.0.0.1:7001
    

    输入你想重新分配的哈希槽数量

    How many slots do you want to move (from 1 to 16384)?
    

    输入你想接收这些哈希槽的节点ID

    What is the receiving node ID?
    

    输入想从哪个节点移动槽点,选择all表示所有其他节点,也可以依次输入节点ID,以done结束。

    Please enter all the source node IDs.
      Type 'all' to use all the nodes as source nodes for the hash slots.
      Type 'done' once you entered all the source nodes IDs.
    Source node #1:

    输入yes执行重新分片

    Do you want to proceedwith the proposed reshard plan (yes/no)?
    

    自动故障转移

    当运行中的master节点挂掉了,集群会在该master节点的slave节点中选出一个作为新的master节点。这里不做演示。

    手动故障转移

    有的时候在主节点没有任何问题的情况下强制手动故障转移也是很有必要的,比如想要升级主节点的Redis进程,我们可以通过故障转移将其转为slave再进行升级操作来避免对集群的可用性造成很大的影响。

    Redis集群使用 cluster failover 命令来进行故障转移,不过要在被转移的主节点的从节点上执行该命令(使用redis-cli连接slave节点并执行 cluster failover命令进行转移)。

    添加一个主节点

    按之前的方式再复制一份配置文件,并修改配置

    /usr/local/redis-5.0.4/redis-cluster-conf/7007/redis.conf

    然后启动该Redis服务,执行以下命令将该节点添加到集群中去

    ./src/redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001
    

    第一个参数为新增加的节点的IP和端口,第二个参数为任意一个已经存在的节点的IP和端口。

    此时该新节点已经成为集群的一份子

    127.0.0.1:7007> cluster nodes
    90c78386c39c8258435b5b61f49a623b358ec8a6 127.0.0.1:7007@17007 myself,master - 0 1553239975877 10 connected
    c4180e02149e2d853a80683433773ef4bceffc78 127.0.0.1:7001@17001 master - 0 1553240017595 11 connected 0-5544 10923-11004
    b6584514edbf57331a65f367304f33ad1bd0903e 192.168.1.164:7005@17005 slave 3bdbc4ac0d5902dcf8a5ebbfb88db8fad224c066 0 1553240016992 2 connected
    07000b3a905df0ab0c86361adcb2774a487ce650 192.168.1.164:7004@17004 slave c4180e02149e2d853a80683433773ef4bceffc78 0 1553240016000 11 connected
    28fa7bbf6b2a46991c7a5fe8eec53db1a5f1e9f6 192.168.1.164:7003@17003 master - 0 1553240017595 3 connected 11005-16383
    3bdbc4ac0d5902dcf8a5ebbfb88db8fad224c066 192.168.1.164:7002@17002 master - 0 1553240017000 2 connected 5545-10922
    fd9cba359d94ba6c9beecc91fbd491f9cf7a39ca 192.168.1.164:7006@17006 slave 28fa7bbf6b2a46991c7a5fe8eec53db1a5f1e9f6 0 1553240016000 3 connected

    但是该节点没有包含任何的哈希槽,所以没有数据会存到该主节点。我们可以通过上面的集群重新分片给该节点分配哈希槽,那么该节点就成为了一个真正的主节点了。

    添加一个从节点

    跟添加主节点一样添加一个节点7008,然后连接上该节点并执行如下命令

    cluster replicate<nodeId>
    

    这样就可以指定该节点成为哪个节点的从节点。

    节点的移除

    可以使用如下命令来移除节点

    ./src/redis-cli --cluster del-node 127.0.0.1:7001 <nodeId>
    

    第一个参数是任意一个节点的地址,第二个参数是你想要移除的节点ID。如果是移除主节点,需要确保这个节点是空的,如果不是空的则需要将这个节点上的数据重新分配到其他节点上。

    程序中使用

    SpringBoot中连接Redis集群配置

    spring:
      redis:
        cluster:
          nodes: 192.168.1.164:7001,192.168.1.164:7002,192.168.1.164:7003,192.168.1.164:7004,192.168.1.164:7005,192.168.1.164:7006
        database: 0
        password: <password>
    

    参考文档

    http://www.redis.cn/topics/cluster-tutorial.html

    展开全文
  • redis主从复制(读写分离) redis哨兵模式 Redis配置详解 一、Redis主从搭建 本文讲解用的是Redis5.0.10搭建一主二从 Redis官方下载连接:http://download.redis.io/releases/ IP PORT 哨兵端口 Redis-...
  • Redis(四)------redis主从复制原理

    千次阅读 2019-12-17 20:56:08
    主从模式指的是使用一个redis实例作为主机,其余的实例作为备份机。 数据备份:主机和从机的数据完全一致,主机支持数据的写入和读取等各项操作,而从机则只支持与主机数据的同步和读取,也就是说,客户端可以...
  • 配置Redis主从复制服务3.模拟主服务器挂掉后三、哨兵模式原理1.哨兵的主要作用1.现象2.原因2.哨兵部署流程1.模拟主服务器出现问题down下来,查看从服务器状态变化2.查看之前配置的哨兵检测的主服务器地址情况3.查看...
  • (5)Redis主从同步原理及详细配置

    千次阅读 2019-04-17 02:08:16
    尽管Redis的性能很好,但是有时候依旧满足不了应用的需要,比如过多的用户进入主页,导致Redis被频繁访问,此时就存在大量的读操作。 对于一些热门网站的某个时刻(比如促销商品的时候)每秒成千上万的请求是...
  • 1.设立一个主机作为哨兵,用来监听和找一个优先级高的最为要附属主机BOSS。 2.哨兵发布心跳ping,判断主机是否存活。 3.首先部署好一主二仆模式环境。 4.在/myredis目录下,建一个...执行redis-sentinel /myredis/senti
  • 10.【Redis主从架构】redis哨兵核心原理的深入解析(包括slave选举算法) 1. sdown和odown转换机制 1.1 sdown-主观宕机 sdown是主观宕机,就一个哨兵如果自己觉得一个master宕机了,那么就是主观宕机了。 主观宕机...
  • 1.主从架构的核心原理: 当启动一个salve node时会发送PSYNC 命令到master。 salve第一次连接master时master会根据当前数据复制一份RDB(full resynchronization 全量复制)到slave,slave会将本地数据写入磁盘,然后...
  • 一 ,Linux安装Redis1.我们先配置redis的 yum 源 , 很多软件的找不到 yum 源 我们可以使用 EPEL 找到很多软件的yum源2.使用命令 yum install epel-release -y 下载 EPEL 3.然后使用 yum 下载 redis,yum install ...
  • redis主从

    2019-11-15 13:57:11
    redis主从 redis主从    Redis支持主从复制分为全量同步和增量同步,首次同步是全量同步,主从同步可以让slave从master备份数据,而且slave还可与有slave器,即另外一台redis服务器可以从一台slave进行数据同步。...
  • redis主从复制下哨兵模式---选举原理

    千次阅读 2019-05-06 13:37:55
    redis主从复制下哨兵模式---选举原理 一.哨兵机制 任务:  有了主从复制的实现以后,如果想对主服务器进行监控,那么在redis2.6以后提供了一个"哨兵"的机制。顾名思义,哨兵的含义就是监控redis系统的运行...
  • Redis 主从复制

    2021-07-01 20:06:25
    Redis 主从复制
  • Sentinel(哨兵)的来由书接上文,我们学习了redis的replication的原理,我们这一章来讨论一下redis主从策略的高可用性。这个哨兵的插件是我们redis里面集成了的(部署简单略),哨兵会监控主从的各个节点状态,当主...
  • 文章目录前言一、Redis主从复制的作用二、Redis主从复制环境配置1.查看默认配置信息2.配置一主二从的集群模式2.1.拷贝配置文件2.2.配置redis79.conf文件2.3.配置redis80.conf文件3.依次启动三个服务4.进入三台服务,...
  • 1.redis主从关系104服务器为主redis, 105服务器为104的从服务器 , 105作为106的主服务器 ,106为105的从服务器 2.redis之前配置可参考https://blog.csdn.net/yanghzaini/article/details/85314808 3.配置105,106...
  • Redis-18Redis主从同步

    千次阅读 2018-10-05 23:32:22
    文章目录概述主从同步Redis主从同步配置主服务器从服务器Redis主从同步过程缺点 概述 尽管 Redis 的性能很好,但是有时候依旧满足不了应用的需要,比如过多的用户进入主页,导致 Redis 被频繁访问,此时就存在大量的...
  • Redis主从复制

    2021-05-04 10:18:27
    目录Redis主从复制Redis搭建一主多从Redis主从复制-哨兵模式 Redis主从复制 是什么 主机数据更新后根据配置和策略, 自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主 Redis搭建一主多从 搭建...
  • Redis 主从+哨兵配置

    2019-03-13 16:05:28
    原文传送门:redis主从配置一,redis主从配置二 主从配置一 一、本文目的 Redis的主从配置分为两篇文章,第一篇主要介绍了Redis主从配置的搭建过程及使用,第二篇主要说明各种情况下Redis主从状态,如Master...
  • Redis主从复制、哨兵模式、集群一、Redis主从复制1、Redis主从复制概念2、Redis主从复制的作用3、主从复制的流程4、搭建Redis主从复制(1)环境配置(2)安装redis(3)修改master节点redis配置文件 一、Redis主从...
  • 我在这篇博客详细讲解Redis主从结构配置以及复制原理(一)中讲了Redis2.6版本的主从结构和全量主从复制原理,接下来我会继续讲讲Redis2.8版本之后引入的增量主从复制原理
  • Redis主从哨兵集群

    2019-11-12 19:55:37
    Redis:Redis主从复制哨兵机制及集群搭建 Redis主从复制 什么是主从复制 持久化保证了即使Redis服务重启也不会丢失数据,因为Redis服务重启后会将硬盘上持久化的数据恢复到内存中,但是当Redis服务器的硬盘损坏了...
  • Redis主从和集群配置

    2020-09-07 22:35:58
    Redis主从和集群配置Redis主从配置一、持久化RDB模式AOF模式二、主从复制1. 主从复制原理2. 主从配置三、哨兵模式1. 哨兵模式介绍2. 哨兵工作方式2.1 监控过程 Redis主从配置 一、持久化 因为Redis数据是在内存中的...
  • Redis 主从复制详解

    2020-03-11 22:47:05
    Redis 主从复制详解 文章目录Redis 主从复制详解1、 1、 port 6379 pidfile /var/run/redis_6379.pid logfile “6379.log” dbfilename dump6379.rdb appendfilename “appendonly6379.aof” ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,312
精华内容 5,324
热门标签
关键字:

redis主从选举原理

redis 订阅