精华内容
下载资源
问答
  • Redis 主从复制、哨兵和集群区别
    2021-10-17 16:07:11

    转自:Redis 主从复制、哨兵和集群区别,更优体验:http://www.kongzid.com/

    目录

    1、主从复制(Replication)

    1.1 主从数据库

    1.2 主从复制的特点

    1.3 主从复制的优缺点

    2、哨兵(Sentinel)

    2.1 Redis哨兵主要功能

    2.2 Redis哨兵高可用原理

    2.3 Redis哨兵故障切换的过程

    2.4 Redis哨兵模式的工作方式

    2.5 Redis哨兵模式的优缺点

    3、集群(Cluster)

    3.1 Redis-Cluster集群的配置

    3.2 Redis-Cluster集群的特点

    3.3 Redis-Cluster集群的工作方式

    3.4 Redis-Cluster集群的优缺点


    Redis Cluster是Redis的分布式集群解决方案,在 3.0 版本正式推出。在3.0之前的集群方案主要是主从复制和哨兵机制,3种方案各有优缺点。

    • 主从复制(Replication)主要是备份数据、读写分离、负载均衡,一个Master可以有多个Slaves服务器作为备份。
    • 哨兵(Sentinel)是为了高可用,可以管理多个Redis服务器,提供了监控,提醒以及自动的故障转移的功能。sentinel发现master挂了后,就会从slave(从服务器)中重新选举一个master(主服务器)。
    • 集群(cluster)则是为了解决单机Redis容量有限/能力有限的问题,将数据按一定的规则分配到多台机器,提高并发量,内存/QPS不受限于单机,可受益于分布式集群高扩展性。

    1、主从复制(Replication)

    同Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了解决单点数据库问题,分担读压力,Redis支持主从复制(把数据复制多个副本部署到其他节点上),读写分离,实现Redis的高可用性,冗余备份保证数据和服务的高度可靠性。一个Master可以有多个Slaves。

    • ①从数据库向主数据库发送sync(数据同步)命令。
    • ②主数据库接收同步命令后,会保存快照,创建一个RDB文件。
    • ③当主数据库执行完保持快照后,会向从数据库发送RDB文件,而从数据库会接收并载入该文件。
    • ④主数据库将缓冲区的所有写命令发给从服务器执行。
    • ⑤以上处理完之后,之后主数据库每执行一个写命令,都会将被执行的写命令发送给从数据库。
    • 注意:在Redis2.8之后,主从断开重连后会根据断开之前最新的命令偏移量进行增量复制

    1.1 主从数据库

    在复制的概念中,数据库分为两类,一类是主数据库(master),另一类是从数据库(slave)。主数据库可以进行读写操作,当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的,并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库,而一个从数据库只能拥有一个主数据库。

    1.2 主从复制的特点

    • 主数据库可以进行读写操作,当读写操作导致数据变化时会自动将数据同步给从数据库
    • 从数据库一般都是只读的,并且接收主数据库同步过来的数据
    • 一个master可以拥有多个slave,但是一个slave只能对应一个master
    • slave挂了不影响其他slave的读和master的读和写,重新启动后会将数据从master同步过来
    • master挂了以后,不影响slave的读,但redis不再提供写服务,master重启后redis将重新对外提供写服务
    • master挂了以后,不会在slave节点中重新选一个master

    1.3 主从复制的优缺点

    优点:

    1. 支持主从复制,主机会自动将数据同步到从机,数据备份的同时可以进行读写分离,提高服务器性能;
    2. 为了分载Master的读操作压力,Slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由Master来完成;
    3. Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力;
    4. Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间,客户端仍然可以提交查询或修改请求;
    5. Slave Server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,Redis则返回同步之前的数据;

    缺点:

    1. Redis不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的IP才能恢复;
    2. 主机宕机,宕机前有部分数据未能及时同步到从机,切换IP后还会引入数据不一致的问题,降低了系统的可用性;
    3. 如果多个Slave断线了,需要重启的时候,尽量不要在同一时间段进行重启。因为只要Slave启动,就会发送sync请求和主机全量同步,当多个 Slave 重启的时候,可能会导致 Master IO剧增从而宕机。
    4. Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂;

    2、哨兵(Sentinel)

    主从同步/复制的模式,当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。哨兵是Redis集群架构中非常重要的一个组件,哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

    哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

    Redis Sentinel是社区版本推出的原生高可用解决方案,其部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群。

    其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群,可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。

    2.1 Redis哨兵主要功能

    • 集群监控:负责监控Redis master和slave进程是否正常工作
    • 消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
    • 故障转移:如果master node挂掉了,会自动转移到slave node上
    • 配置中心:如果故障转移发生了,通知client客户端新的master地址

    2.2 Redis哨兵高可用原理

    当主节点出现故障时,由Redis Sentinel自动完成故障发现和转移,并通知应用方,实现高可用性。

    • 哨兵机制建立了多个哨兵节点(进程),共同监控数据节点的运行状况。
    • 同时哨兵节点之间也互相通信,交换对主从节点的监控状况。
    • 每隔1秒每个哨兵会向整个集群:Master主服务器+Slave从服务器+其他Sentinel(哨兵)进程,发送一次ping命令做一次心跳检测。

    这个就是哨兵用来判断节点是否正常的重要依据,涉及两个概念:主观下线和客观下线。

    • 主观下线:一个哨兵节点判定主节点down掉是主观下线。
    • 客观下线:只有半数哨兵节点都主观判定主节点down掉,此时多个哨兵节点交换主观判定结果,才会判定主节点客观下线。

    基本上哪个哨兵节点最先判断出这个主节点客观下线,就会在各个哨兵节点中发起投票机制Raft算法(选举算法),最终被投为领导者的哨兵节点完成主从自动化切换的过程。

    2.3 Redis哨兵故障切换的过程

    假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行 failover 过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行 failover 操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。对于客户端而言,一切都是透明的。

    2.4 Redis哨兵模式的工作方式

    1. 每个Sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的Master主服务器,Slave从服务器以及其他Sentinel(哨兵)进程发送一个 PING 命令。
    2. 如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel(哨兵)进程标记为主观下线(SDOWN)
    3. 如果一个Master主服务器被标记为主观下线(SDOWN),则正在监视这个Master主服务器的所有 Sentinel(哨兵)进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
    4. 当有足够数量的 Sentinel(哨兵)进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN), 则Master主服务器会被标记为客观下线(ODOWN)
    5. 在一般情况下, 每个 Sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
    6. 当Master主服务器被 Sentinel(哨兵)进程标记为客观下线(ODOWN)时,Sentinel(哨兵)进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
    7. 若没有足够数量的 Sentinel(哨兵)进程同意 Master主服务器下线, Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel(哨兵)进程发送 PING 命令返回有效回复,Master主服务器的主观下线状态就会被移除。

    2.5 Redis哨兵模式的优缺点

    优点:

    1. 哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。
    2. 主从可以自动切换(自动化故障恢复),系统更健壮,可用性更高。

    缺点:

    1. Redis较难支持在线动态扩容,在集群容量达到上限时在线扩容会变得很复杂。
    2. Redis 数据节点中 slave 节点作为备份节点不提供服务

    3、集群(Cluster)

    Redis 的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台 Redis 服务器都存储相同的数据,浪费内存且有木桶效应,所以在redis3.0上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,也就是说每台 Redis 节点上存储不同的内容。

    Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。

    Redis Cluster着眼于提高并发量。集群至少需要3主3从,且每个实例使用不同的配置文件,主从不用配置,集群会自己选。

    在redis-cluster架构中,redis-master节点一般用于接收读写,而redis-slave节点则一般只用于备份, 其与对应的master拥有相同的slot集合,若某个redis-master意外失效,则再将其对应的slave进行升级为临时redis-master。

    当有请求是在向slave发起时,会直接重定向到对应key所在的master来处理。 但如果不介意读取的是redis-cluster中有可能过期的数据并且对写请求不感兴趣时,则亦可通过readonly命令,将slave设置成可读,然后通过slave获取相关的key,达到读写分离。具体可以参阅redis官方文档等相关内容。

    3.1 Redis-Cluster集群的配置

    使用集群,只需要将每个数据库节点的cluster-enable配置打开即可。根据官方推荐,集群部署至少要 3 台以上的master节点(因为选举投票的机制,所以必须为奇数),最好使用 3 主 3 从六个节点的模式。在测试环境中,只能在一台机器上面开启6个服务实例来模拟。

    3.2 Redis-Cluster集群的特点

    1. 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
    2. 节点的fail是通过集群中超过半数的节点检测失效时才生效。
    3. 客户端与 Redis 节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
    4. 所有的节点都是一主一从(也可以是一主多从),其中从节点不提供服务,仅作为备用
    5. 支持在线增加、删除节点
    6. 客户端可以连接任何一个主节点进行读写

    3.3 Redis-Cluster集群的工作方式

    在 Redis 的每一个节点上,都有这么两个东西,一个是插槽(slot),它的的取值范围是:0-16383。还有一个就是cluster,可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候,Redis 会根据 crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。

    Redis 集群使用数据分片(sharding)而非一致性哈希(consistency hashing)来实现: 一个 Redis 集群包含 16384 个哈希槽(hash slot), 数据库中的每个键都属于这 16384 个哈希槽的其中一个, 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

    集群中的每个节点负责处理一部分哈希槽。 举个例子, 一个集群可以有三个哈希槽, 其中:

    节点 A 负责处理 0 号至 5500 号哈希槽。
    节点 B 负责处理 5501 号至 11000 号哈希槽。
    节点 C 负责处理 11001 号至 16384 号哈希槽。
    这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。

    为了保证高可用,redis-cluster集群引入了主从模式,一个主节点对应一个或者多个从节点,当主节点宕机的时候,就会启用从节点。当其它主节点ping一个主节点A时,如果半数以上的主节点与A通信超时,那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了,那么该集群就无法再提供服务了。

    3.4 Redis-Cluster集群的优缺点

    优点

    1. 解决分布式负载均衡的问题。具体解决方案是分片/虚拟槽slot。
    2. 可实现动态扩容
    3. P2P模式,无中心化

    缺点

    1. 为了性能提升,客户端需要缓存路由表信息
    2. Slave在集群中充当“冷备”,不能缓解读压力
    更多相关内容
  • redis 哨兵和 集群

    2021-01-06 16:49:42
    哨兵模式# 哨兵模式是redis高可用的实现方式之一 使用一个或者多个哨兵(Sentinel)实例... 哨兵节点会配置的主节点建立起两条连接命令连接订阅连接 哨兵会通过命令连接每10s发送一次INFO命令,通过INFO命令,主..

    哨兵模式

    哨兵模式是redis高可用的实现方式之一
    使用一个或者多个哨兵(Sentinel)实例组成的系统,对redis节点进行监控,在主节点出现故障的情况下,能将从节点中的一个升级为主节点,进行故障转义,保证系统的可用性。

     

    哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的

    1. 首先主节点的信息是配置在哨兵(Sentinel)的配置文件中
    2. 哨兵节点会和配置的主节点建立起两条连接命令连接订阅连接
    3. 哨兵会通过命令连接每10s发送一次INFO命令,通过INFO命令,主节点会返回自己的run_id和自己的从节点信息
    4. 哨兵会对这些从节点也建立两条连接命令连接订阅连接
    5. 哨兵通过命令连接向从节点发送INFO命令,获取到他的一些信息
      a. run_id
      b. role
      c. 从服务器的复制偏移量 offset
      d. 等
    6. 因为哨兵对与集群中的其他节点(主从节点)当前都有两条连接,命令连接订阅连接
      a. 通过命令连接向服务器的_sentinel:hello频道发送一条消息,内容包括自己的ip端口、run_id、配置纪元(后续投票的时候会用到)等
      b. 通过订阅连接对服务器的_sentinel:hello频道做了监听,所以所有的向该频道发送的哨兵的消息都能被接受到
      c. 解析监听到的消息,进行分析提取,就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了,更新结构体将这些哨兵节点记录下来
      d. 向观察到的其他的哨兵节点建立命令连接----没有订阅连接

    哨兵模式下的故障迁移

    主观下线

    哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令,如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)以外的响应,哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

    客观下线

    当一个哨兵节点发现主节点处于主观下线状态是,会向其他的哨兵节点发出询问,该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时,该哨兵节点就会将自己维护的结构体中该主节点标记为SRI_O_DOWN客观下线
    询问命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>

    参数意义
    ip/port当前认为下线的主节点的ip和端口
    current_epoch配置纪元
    run_id*标识仅用于询问是否下线
    有值标识该哨兵节点希望对方将自己设置为leader
    询问时用*,选举时用run_id

    leader选举

    在认为主节点客观下线的情况下,哨兵节点节点间会发起一次选举,命令还是上面的命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>,只是run_id这次会将自己的run_id带进去,希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leader的情况下,会有该leader对故障进行迁移

    故障迁移

    1. 在从节点中挑选出新的主节点
      a. 通讯正常
      b. 优先级排序
      c. 优先级相同是选择offset最大的
    2. 将该节点设置成新的主节点 SLAVEOF no one,并确保在后续的INGO命令时,该节点返回状态为master
    3. 将其他的从节点设置成从新的主节点复制, SLAVEOF命令
    4. 将旧的主节点变成新的主节点的从节点

    优缺点

    • 优点
      高可用,在主节点故障时能实现故障的转移
    • 缺点:好像没办法做到水平拓展,如果内容很大的情况下

    集群模式

    官方提供的分布式方案(槽指派/重新分片/故障转移)
    集群内的节点,都会有个数据结构存储整个集群内的节点信息

    //整体
    struct clusterState{
      clusterNode *mySelf;
      ....
      dict *nodes;  //集群内的所有节点
    }
    
    // 单个节点
    struct clusterNode {
      char name[];
      char ip[];
      int port;
      clusterLink *link;  //保存节点间,连接的信息
      int flags;    //状态标记
    }
    
    //节点间连接的信息
    struct clusterLink{
      mstime_t ctime;  //创建时间
      int fd; //tcp套接字描述符
      sds sndbuf;  // 输出缓存区
      sds rcvbuf;  //输入缓存区
      struct clusterNode *node;
    }
    
    

     

    槽指派

    redis集群可以被分为16384个槽,只有这些槽全被指派了处理的节点的情况下,集群的状态才能是上线状态(ok)
    操作redis集群的时候,将key作为参数,就可以计算出对应的处理槽上,所以存储等操作都应该在该槽对应的节点上。通过这种方式,可以完美的实现集群存储的水平拓展。

    def slot_number(key):
      return CRC16(key) & 16383
    //得到的结果就是槽的序号
    

    槽指派的信息是怎么存储的

    struct clusterState{
      clusterNode *slots[16384]
     }
    
    struct clusterNode{
      unsigned char slots[16384/8]
    }
    

    通过上面两个结构体中的定义可以看出,槽指派的信息是分了两种方式,保存在结构体里面。

     

     

    分两种存储的好处
    1. 如果需要判断某一个节点负责的槽,只需要获取方式二中的数组做判断就可以
    2.如果找某个槽是哪个节点负责,只需要获取方式一的列表,一查就知道

    重新分片

    将已经指派给节点的槽,重新执行新的节点。

     

    故障转移

    发现故障节点

    1. 集群内的节点会向其他节点发送PING命令,检查是否在线
    2. 如果未能在规定时间内做出PONG响应,则会把对应的节点标记为疑似下线
    3. 集群中一半以上负责处理槽的主节点都将主节点X标记为疑似下线的话,那么这个主节点X就会被认为是已下线
    4. 向集群广播主节点X已下线,大家收到消息后都会把自己维护的结构体里的主节点X标记为已下线

    从节点选举

    1. 当从节点发现自己复制的主节点已下线了,会向集群里面广播一条消息,要求所有有投票权的节点给自己投票(所有负责处理槽的主节点都有投票权)
    2. 主节点会向第一个给他发选举消息的从节点回复支持
    3. 当支持数量超过N/2+1的情况下,该从节点当选新的主节点

    故障的迁移

    1. 新当选的从节点执行 SLAVEOF no one,修改成主节点
    2. 新的主节点会撤销所有已下线的老的主节点的槽指派,指派给自己
    3. 新的主节点向集群发送命令,通知其他节点自己已经变成主节点了,负责哪些槽指派
    4. 新的主节点开始处理自己负责的槽的命令

    集群模式和哨兵模式的区别

    1. 哨兵模式监控权交给了哨兵系统,集群模式中是工作节点自己做监控
    2. 哨兵模式发起选举是选举一个leader哨兵节点来处理故障转移,集群模式是在从节点中选举一个新的主节点,来处理故障的转移
    展开全文
  • Redis哨兵模式集群部署

    一、环境信息

    1、redis哨兵模式版本要求
    redis 2.6版本开始提供,稳定版本为2.8及之后;
    2、服务节点个数要求
    至少需部署3个且奇数个哨兵节点;
    3、特性
    哨兵进程作用:监控、提醒、自动故障转移、配置提供者;
    优点:基于主从模式的升级,解决主从复制的缺陷;
    缺点:在线扩容困难、配置繁琐;
    4、投产部署说明
    本文档是在一台服务器上启动了6个redis实例进行演示。实际投产部署时,每个节点应该对应一台服务器,每个节点配置为自己主机的IP信息即可。
    5、本文档部署信息
    在这里插入图片描述
    注:默认使用root权限账户进行安装部署

    二、Redis哨兵模式部署

    在这里插入图片描述

    (1)创建配置文件目录

    ①$ mkdir -p /usr/local/redis-sentinel #自行指定路径
    ②$ mkdir -p /opt/soft/redis/data/ #自行指定路径
    ③$ mkdir -p /var/run/ #自行指定路径

    (2)配置主节点

    ①$ vim /usr/local/redis-sentinel/redis-7000.conf #新建配置文件
    添加如下信息:
    在这里插入图片描述

    (3)配置从节点

    注:本文档主从节点在同一台服务器,实际生成部署时需替换为主节点IP和端口
    ①$ vim /usr/local/redis-sentinel/redis-7001.conf #新建配置文件
    添加信息:
    在这里插入图片描述
    ②$ vim /usr/local/redis-sentinel/redis-7002.conf #新建配置文件
    添加信息:
    在这里插入图片描述

    (4)启动主、从节点

    ①$ redis-server /usr/local/redis-sentinel/redis-7000.conf
    ②$ redis-server /usr/local/redis-sentinel/redis-7001.conf
    ③$ redis-server /usr/local/redis-sentinel/redis-7002.conf
    ④$ ps -ef | grep redis 查看redis节点进程信息
    在这里插入图片描述

    (5)查看主从节点配置信息

    分别连接主从节点客户端,在客户端使用info replication命令查看角色信息
    ①$ redis-cli -p 7000 #查看主节点信息如下:
    在这里插入图片描述

    ②$ redis-cli -p 7001 #Slave1从节点信息如下:
    在这里插入图片描述
    ③$ redis-cli -p 7002 Slave2从节点信息如下:
    在这里插入图片描述

    (6)配置哨兵

    ①$ cp /%redis安装包的解压目录%/sentinel.conf /usr/local/redis-sentinel
    #拷贝Sentinel配置文件
    ②$ cd /usr/local/redis-sentinel
    目前redis-sentinel配置文件目录如下:
    在这里插入图片描述
    ③$ cat sentinel.conf | grep -v “#” | grep -v “^$” > redis-sentinel-26379.conf
    #拷贝文件并去除空行和注释

    ④$ cat sentinel.conf | grep -v “#” | grep -v “^$” > redis-sentinel-26380.conf

    ⑤$ cat sentinel.conf | grep -v “#” | grep -v “^$” > redis-sentinel-26381.conf

    ⑥$ vim redis-sentinel-26379.conf #修改后配置信息如下:
    在这里插入图片描述
    ⑦$ vim redis-sentinel-26380.conf #修改后配置信息如下:
    在这里插入图片描述

    ⑧$ vim redis-sentinel-26381.conf #修改后配置信息如下:
    在这里插入图片描述

    (7)启动哨兵

    ①$ redis-sentinel redis-sentinel-26379.conf
    ②$ redis-sentinel redis-sentinel-26380.conf
    ③$ redis-sentinel redis-sentinel-26381.conf
    ④$ ps -ef | grep redis-sentinel #查看哨兵进程信息
    在这里插入图片描述

    (8)查看哨兵模式集群信息

    ①$ ps -ef | grep redis #查看哨兵模式各节点进程信息
    在这里插入图片描述
    ②$ redis-cli -p 26379 #使用redis客户端连接到Sentinel;
    在这里插入图片描述
    ③连接后使用ping命令查看redis主从服务是否正常:返回PONG正常
    在这里插入图片描述

    ④使用info sentinel 查看哨兵配置信息:
    可以看到本集群已经搭建好:3个sentinel、一个master节点、两个slave节点
    在这里插入图片描述

    展开全文
  • Redis哨兵集群配置

    2018-05-18 09:25:50
    Redis哨兵集群配置的详细步骤。在监控主从结构时,所有的哨兵进程都会调用info 命令,查看当前主从状态,一旦发现返回结果中master宕机了,所有哨兵将会进行投票选举(过半选举),选出替代主节点的节点继续执行对外服务
  • Docker搭建Redis哨兵模式集群1、哨兵模式概述2、Docker搭建哨兵模式集群2.1 先按照如下链接中方法搭建一个一主二从的Redis集群,其中redis-master1是主服务器,redis-salve11redis-salve22是从服务器。2.2 在/root...

    1、哨兵模式概述

      基于主从复制模式的集群在发生故障时可能会出现数据丢失等情况,因为当主服务器发生故障后,需要手动进行数据恢复动作,并要重新设置主从关系,比较麻烦。
      可以在主从复制的基础上引入“哨兵(sentinel)”机制,一方面用哨兵远程监控主从服务器是否可用,另一方面当主服务器发生故障时通过哨兵机制可以实现“故障自动恢复”效果。
    一般来说,哨兵机制会和主从复制模式整合使用,在基于哨兵的模式里会在一台或多台服务器上引入哨兵进程,这些节点也叫哨兵节点。
      哨兵节点一般不存储数据,它的作用是监控主从模式里的主服务器节点。当哨兵节点监控的主服务器发生故障时,哨兵节点会主导“故障自动恢复”流程,具体来讲就是会在该主服务器下属的从服务器里选出一个新的主服务器,并完成响应的数据和配置更改等动作。
      也就是说,如果采用这种模式,可以让故障自动修复,从而提升系统的可用性。在项目里,一般会配置多个主从模式集群,所以会引入多个哨兵节点。基于哨兵模式的集群效果如下图所示。
    在这里插入图片描述

    2、Docker搭建哨兵模式集群

    2.1 先按照如下链接中方法搭建一个一主二从的Redis集群,其中redis-master1是主服务器,redis-salve11和redis-salve22是从服务器。

    Docker搭建Redis主从复制集群https://blog.csdn.net/qq_43753724/article/details/120390533?spm=1001.2014.3001.5501
    在这里插入图片描述

    2.2 在/root/redisconf/文件夹下新建sentinel1.conf配置文件

    文件内容如下:

    port 16379
    sentinel monitor master 172.17.0.5 6382 2
    dir /
    logfile "sentinel1.log"
    

    port 16379 哨兵节点的工作端口为16379 sentinel monitor master 172.17.0.5 6382 2
    指定监控对象,其中master是哨兵节点为监控服务器指定的名字,172.17.0.5和6382分别是redis-master1这台主服务器的IP地址和端口号,最后的2表示至少需要2台哨兵节点认可才能认定该主服务器失效。

    2.3 新建redis-sentinel1容器(第一个哨兵节点)

    docker run -itd --privileged=true --name redis-sentinel1 -v /root/redisconf/:/usr/local/etc/redis -p 16379:16379 redis:latest redis-sentinel /usr/local/etc/redis/sentinel1.conf
    

    在这里插入图片描述
      这里通过-v挂在了/root/redisconfig/目录,同时使用-p指定了Docker容器16379端口映射宿主机16369端口。这里用redis-sentinel命令启动了哨兵节点,启动时加载了sentinel1.conf文件。

    2.4 查看哨兵节点信息

      通过dodkcer exec -it redis-sentinel1 /bin/bash命令进入Docker容器里的命令行,然后用redis-cli -h 127.0.0.1 -p 16379命令进入Redis客户端,在Redis客户端里,用info sentinel命令查看哨兵节点的信息,具体如下:
    在这里插入图片描述
      从最后一行可以看到,该哨兵节点监控的主服务器状态(status)是ok,slaves数量为2,即该主服务器有两个从服务器,这和之前的配置情况是一致的。

    2.5 新建redis-sentinel2容器(第二个哨兵节点)

    在/root/redisconf/目录下创建sentinel2.conf文件,代码如下:

    port 16380
    sentinel monitor master 172.17.0.5 6382 2
    dir “/”
    logfile "sentinel2.log"
    

    随后开启命令窗口,新建哨兵节点:

     docker run -itd --privileged=true --name redis-sentinel2 -v /root/redisconf/:/usr/local/etc/redis -p 16380:16380 redis:latest redis-sentinel /usr/local/etc/redis/sentinel2.conf
    

    在这里插入图片描述
    此时的所有容器
    在这里插入图片描述
    继续进入客户端查看哨兵节点信息
    在这里插入图片描述
      可以看到,该哨兵正在监控172.17.0.5:6382指向的主服务器,sentinels=2表示172.17.0.5:6382指向的主服务器正在被两台哨兵节点监控。
      至此,哨兵集群搭建完成。

    3、哨兵节点的常用配置

    3.1 指定判断下线时间的阈值

    sentinel down-after-millseconds master 60000
    

      其中,master表示该哨兵节点监控的服务器名,需要和sentinel monitor配置项里指定的服务器名保持一致,而60000表示时间,单位是毫秒。也就是说,如果在69秒里该哨兵节点没有收到master服务器的正确响应,就会认为该服务器已经下线失效。

    3.2 设置故障恢复的时效

    sentinel failover-timeout master 180000
    

      该时效参数的单位是毫秒,这里的含义是,在进行故障恢复时,如果在180秒里还没有完成主从服务器的切换动作,就会认为本次恢复动作失败。

    4、哨兵模式下的故障自动恢复效果

      通过上文的配置,能实现哨兵节点监控主从复制模式里主服务器的效果。这里将演示主服务器失效后故障子u东恢复效果。

    4.1 停止主服务器(redis-master1)所在的容器

      到redis-master1这个Docker容器下,执行docker stop redis-master1命令来停止主服务器所在的容器,以此来模拟主服务器失效的效果。
    在这里插入图片描述

    4.2 观察哨兵节点所监控的主从集群状态

      到redis-sentinel1这个哨兵节点所在的命令行窗口,通过info sentinel命令观察该哨兵节点所监控的主从集群状态。
    在这里插入图片描述
      从输出结果可以看到,在该哨兵节点所在的集群里,主服务器已从172.17.0.5:6382换成172.17.0.7:6384。也就是说,真个主从复制集群并没有因为主服务器的失效而终止工作,这里哨兵节点把从服务器“提升”为主服务器,从而让该主从复制集群恢复了工作。
      到redis-sentinel2这个哨兵节点所在的命令行窗口,通过info sentinel命令观察该哨兵节点所监控的主从集群状态,也能看到类似的结果。

    4.3 观察redis-slave2所在的命令行窗口,运行info replication命令

    在这里插入图片描述
      从输出看出role的值已经变为了master,也就是从“从服务器”升级成“主服务器”。
      再去redis-slave1所在的命令窗口运行info replication命令,就能看到如下的部分结果,从箭头所指可看出该Redis服务器在redis-master1失效后确实已经从属于172.17.0.7:6384所指向的服务器。
    在这里插入图片描述
    通过本步骤的输出结果,能进一步确认“故障自动恢复”动作已经成功完成。

    5、通过日志观察故障恢复流程

      由于在启动redis-sentinel1和redis-sentinel2节点时制定了日志的路径和位置,这里可以在对应的Docker容器里通过日志观察具体的故障恢复流程。
      先到redis-sentinel1所在的容器里用cat /sentinel1.log命令观察该哨兵节点在故障恢复时的动作,就能看到如下内容
    在这里插入图片描述
      日志中的sdown的含义是“主管下线”,与之对应的是表示客观下线的odown。当本哨兵节点发现所监控的master服务器下线后,会先将它标记为“主管下线”,当多个哨兵节点(根据设置,这里需要2个)都判断服务器下线后,如日志中第1处圈起来那块,随后把该服务器标记为客观下线。
      当检测到客观下线后,会启动故障恢复(failover)流程,通过后面的日志,能看出故障恢复的各个步骤,这些细节可以不用关心。完成故障恢复后,会切换主服务器,切换完成后,会加载从服务器。至此,完成了故障自动恢复的流程。当前主从模式集群效果如下图。
    在这里插入图片描述
      然后到redis-salve2所在的容器,执行cat /sentinel2.log命令查看该哨兵节点的日志,其中和故障恢复相关的内容如下所示。
    在这里插入图片描述
      由于只能由一个哨兵节点完成故障自动恢复的动作,因此如果有多个哨兵节点同时监控到主服务器失效,那么最终只能有一个哨兵节点通过竞争得到故障恢复的权力。
      从上文的日志中可以看到,由于故障恢复的权利已经被redis-sentinel1节点竞争得到,所以当redis-sentinel2节点发现主服务器失效后,只能停留在主管下线(sdown)阶段,而无法进行故障恢复动作。只有当redis-sentinel1节点完成故障恢复动作后,redis-sentienl2节点才能输出后续的日志,感知到重构后的主从复制模式集群,并继续监控该集群里的节点。

    6、故障节点恢复后的表现

      从上文日志可以看到,此时虽然redis-master1服务器依然处于失效状态,但是在新的主从复制集群里依然会把该服务器当成“从服务器”。再到redis-master1所在的命令行窗口用docker start redis-master1命令启动容器,以此来模拟该服务器排除故障后的效果。
    运行完命令后,再到redis-salve22所在的命令行窗口里运行info replication命令,就能看到如下的输出,可以看到故障恢复后的redis-master1服务器会自动以“从服务器”的身份接入
    在这里插入图片描述

      总结,哨兵节点不仅能自动恢复故障,而且当故障节点恢复后会自动把它重新加入到集群中,而无需人工干预。也就是说,与简单的“主从复制模式集群”相比,基于哨兵模式的集群能很好地提升系统地可靠性。

    在这里插入图片描述

    展开全文
  • centos7下Redis哨兵集群和kafka集群zookeeper集群搭建 http://blog.csdn.net/gaowenhui2008/article/details/71516901 https://cwiki.apache.org/confluence/display/KAFKA/Clients
  • redis哨兵集群、应用问题的简述redis主从复制的原理全量同步增量同步哨兵模式哨兵模式监控原理 redis主从复制的原理 Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的...
  • Redis哨兵集群搭建

    2022-03-18 21:49:35
    文章目录1 为什么要使用哨兵模式2 哨兵模式的工作原理3 一主二从三哨兵搭建步骤4 测试该哨兵集群是否可用5 Spring Boot连接Redis哨兵集群 1 为什么要使用哨兵模式 主从模式下,主机会自动将数据同步到从机,为了分...
  • redis哨兵模式.png 哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的 首先主节点的信息是配置在哨兵(Sentinel)的配置文件中 哨兵节点会配置的主节点建立起两条连接命令连接订阅连接 哨兵会...
  • redis哨兵模式集群文档,按照步骤可以实现,非常实用。适合新手操作。
  • Redis 哨兵模式、集群模式

    千次阅读 2021-06-02 20:53:43
    集群监控:负责监控 redis master slave 进程是否正常工作。 消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员。 故障转移:如果 master node 挂掉了,会自动转移到 slave node ...
  • Redis 主从、哨兵和集群 区别

    千次阅读 2019-03-06 13:39:50
    Redis 复制功能的几个重要方面: 一个主服务器可以有多个从服务器。 不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构。 复制功能不会阻塞主服务器: 即使有...
  • 缓存的可靠性可用性至关重要,本章利用Docker+docker-compose+Redis以实现单机版的Redis哨兵模式集群部署,阅读本章需要前置了解Docker容器和Redis哨兵模式的相关知识。 2.Redis主从复制 2.1容器编排 完成主从...
  • 主从模式是最简单的实现高可用的方案,核心就是主从同步。 哨兵(sentinel)的功能比单纯...redis集群redis提供的分布式数据存储方案,集群通过数据分片sharding来进行数据的共享,同时提供复制故障转移的功能。 ...
  • 这是本人在工作中搭建集群的实践经验,当时遇到很多问题,困扰了我好久,最后查看了好多文章成功解决所有问题,主从集群哨兵监听都成功。现在分享出来,我就以一台服务器模拟搭建三台服务器的集群。请务必阅读每一...
  • 实验环境:三台主机,1个master,2个slave 主机名(ip) 角色 server1(192.168.42.28) redis-master server2(192.168.42.29) redis-slave server3(192.168.42.30) redis-slave 1、三个节点修改哨兵配置文件...
  • Redis哨兵集群

    2021-02-22 15:16:10
    Redis的哨兵机制可以实现主从库的自动切换,通过部署多个哨兵实例,就形成了一个哨兵集群哨兵集群中的多个实例共同判断,可以降低对主库下线的误判。一旦实例组成了哨兵集群,即使有哨兵实例出现故障挂掉了,其他...
  • 搭建Redis哨兵集群

    2021-05-18 22:18:19
    搭建Redis哨兵集群 1. 环境准备 准备3台服务器地址为: 192.163.1.11 192.163.1.12 192.163.1.13 并且保证三台机器能供互相ping通 2. 安装Redis 2.1 下载 http://download.redis.io/releases/redis-5.0.7.tar.gz ...
  • redis哨兵集群搭建详细过程

    千次阅读 2022-01-04 13:25:35
    为什么需要哨兵架构2.redis哨兵架构搭建搭建哨兵服务踩坑记录redis主从自动切换自动切换3.Java代码连接哨兵的连接代码-main方法方式-Jedis类Reids连接-springboot方式-RedisTemplate类 架构图 sentinel[ˈsentɪnl]...
  • redis主从、哨兵集群区别

    万次阅读 多人点赞 2019-05-21 15:38:22
    通过持久化功能,Redis保证了即使在服务器重启的情况下也不会损失(或少量损失)数据,因为持久化会把内存中数据保存到硬盘上,重启会从硬盘上加载数据。 。但是由于数据是存储在一台服务器上的,如果这台服务器出现...
  • redis 哨兵集群搭建

    2022-05-10 16:06:28
    部署redis 哨兵集群 一主两从三哨兵集群使用redis6.2.7版本。配置文件中配置 需要结合自己业务特性自己变更。redis哨兵的结构图 一、下载解压压缩包 tail -zxf redis. ...port 6379
  • 文章目录1 Redis安装配置1.1 编译环境配置1.2 Redis安装1.2.1 使用SecureFX把Redis安装包传到centos1.2.2 解压redis安装包1.2.3 编译1.2.4 安装1.2.5 Copy文件2 启动Redis以及客户端2.1 配置redis.conf文件2.2 ...
  • springboot实现Redis哨兵集群

    千次阅读 2022-05-03 01:46:14
    第一步下载Redis3.0以上的版本,因为3.0以下的版本对集群搭建不太友好 第二步解压 第三步安装 以上教程自行百度,下文是本文的重点 进入你安装Redis的目录,复制3个reids.conf配置文件 cp ./redis.conf ./redis6379....
  • springBoot整合Redis,包括整合单机版Redis、redis-cluster集群redis哨兵三种模式
  • 哨兵集群结构 哨兵的作用: 集群监控原理 集群故障恢复原理 小结: Sentinel的三个作用是什么? Sentinel如何判断一个redis实例是否健康? 故障转移步骤有哪些? 哨兵集群结构 哨兵的作用: Redis提供...
  • 哨兵模式强调高可用 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务: 监控(Monitoring): Sentinel 会不断地检查你的主服务器从服务器是否运作正常。 提醒(Notification): ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,969
精华内容 13,187
关键字:

redis哨兵和集群区别

友情链接: Untitled-1.rar