精华内容
下载资源
问答
  • redis集群和哨兵有什么区别呢?哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。(推荐学习:Redis视频教程)监控主数据库从数据库是否正常运行。主数据库出现故障时自动将从数据库转换为主数据库。...

    redis集群和哨兵有什么区别呢?

    哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。(推荐学习:Redis视频教程)

    监控主数据库和从数据库是否正常运行。

    主数据库出现故障时自动将从数据库转换为主数据库。

    sentinel发现master挂了后,就会从slave中重新选举一个master。

    哨兵模式强调高可用

    Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:

    监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

    提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

    自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

    客户端中不会记录redis的地址(某个IP),而是记录sentinel的地址,这样我们可以直接从sentinel获取的redis地址,因为sentinel会对所有的master、slave进行监控,它是知道到底谁才是真正的master的,例如我们故障转移,这时候对于sentinel来说,master是变了的,然后通知客户端。而客户端根本不用关心到底谁才是真正的master,只关心sentinel告知的master。

    集群

    即使使用哨兵,redis每个实例也是全量存储,每个redis存储的内容都是完整的数据,浪费内存且有木桶效应。为了最大化利用内存,可以采用集群,就是分布式存储。即每台redis存储不同的内容,共有16384个slot。每个redis分得一些slot,hash_slot = crc16(key) mod 16384 找到对应slot,键是可用键,如果有{}则取{}内的作为可用键,否则整个键是可用键

    集群至少需要3主3从,且每个实例使用不同的配置文件,主从不用配置,集群会自己选。

    cluster是为了解决单机Redis容量有限的问题,将数据按一定的规则分配到多台机器。

    集群模式提高并发量。

    更多Redis相关技术文章,请访问Redis数据库使用入门教程栏目进行学习!

    展开全文
  • 我们来梳理一下redis主从,redis哨兵,redis机器的区别和关系。 redis主从:是备份关系, 我们操作主库,数据也会同步到从库。 如果主库机器坏了,从库可以上。就好比你 D盘的片丢了,但是你移动硬盘里边备份有。 ...

    至此,我们了解并动手实践了redis的安装,redis单点,redis主从,redis 哨兵 sentinel,redis 集群cluster。
    我们来梳理一下redis主从,redis哨兵,redis机器的区别和关系。

    redis主从:是备份关系, 我们操作主库,数据也会同步到从库。 如果主库机器坏了,从库可以上。就好比你 D盘的片丢了,但是你移动硬盘里边备份有。
    redis哨兵:哨兵保证的是HA,保证特殊情况故障自动切换,哨兵盯着你的“redis主从集群”,如果主库死了,它会告诉你新的老大是谁。
    redis集群:集群保证的是高并发,因为多了一些兄弟帮忙一起扛。同时集群会导致数据的分散,整个redis集群会分成一堆数据槽,即不同的key会放到不不同的槽中。

    主从保证了数据备份,哨兵保证了HA 即故障时切换,集群保证了高并发性。

    一切动手做了才会熟悉。。

    谈到Redis服务器的高可用,如何保证备份的机器是原始服务器的完整备份呢?这时候就需要哨兵和复制。

    1. 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。
    2. 复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。

    Redis正是利用这两个功能来保证Redis的高可用。

    哨兵(sentinal)

    哨兵是Redis集群架构中非常重要的一个组件,哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

    1.Redis哨兵主要功能

    (1)集群监控:负责监控Redis master和slave进程是否正常工作

    (2)消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员

    (3)故障转移:如果master node挂掉了,会自动转移到slave node上

    (4)配置中心:如果故障转移发生了,通知client客户端新的master地址

    2.Redis哨兵的高可用

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

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

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

    1. 主观下线:一个哨兵节点判定主节点down掉是主观下线。

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

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

    Redis 复制(Replication)

    Redis为了解决单点数据库问题,会把数据复制多个副本部署到其他节点上,通过复制,实现Redis的高可用性,实现对数据的冗余备份,保证数据和服务的高度可靠性。

    1.数据复制原理(执行步骤)

    ①从数据库向主数据库发送sync(数据同步)命令。

    ②主数据库接收同步命令后,会保存快照,创建一个RDB文件。

    ③当主数据库执行完保持快照后,会向从数据库发送RDB文件,而从数据库会接收并载入该文件。

    ④主数据库将缓冲区的所有写命令发给从服务器执行。

    ⑤以上处理完之后,之后主数据库每执行一个写命令,都会将被执行的写命令发送给从数据库。

    注意:在Redis2.8之后,主从断开重连后会根据断开之前最新的命令偏移量进行增量复制。

    Redis 主从复制、哨兵和集群这三个有什么区别

     

    1.主从模式:读写分离,备份,一个Master可以有多个Slaves。

    2.哨兵sentinel:监控,自动转移,哨兵发现主服务器挂了后,就会从slave中重新选举一个主服务器。

    3.集群:为了解决单机Redis容量有限的问题,将数据按一定的规则分配到多台机器,内存/QPS不受限于单机,可受益于分布式集群高扩展性。

    哨兵作用于高可用,集群提高并发量,具体Redis集群方案详情,可以参考:高并发架构系列:详解Redis的存储类型、集群架构、以及应用场景

     

     

     

    二、持久化


            那么这么多,这么重要的数据都存储在内存中,如果突然断电,岂不是很糟糕,于是就有了数据的持久化机制,这个其实就是把内存中的数据存储到硬盘中,方便数据的持续存在,也可以减少断电造成的损失。

            那么我们怎么持久化数据呢?多长时间进行一次持久化呢?

    redis 支持两种持久化方式,一种是 Snapshotting(快照)也是默认方式,另一种是 Append-only file(缩写 aof)的方式。下面分别介绍:

         一)、Snapshotting

             快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照,下面是默认的快照保存配置:

        save 900 1 #900 秒内如果超过 1 个 key 被修改,则发起快照保存
        save 300 10 #300 秒内容如超过 10 个 key 被修改,则发起快照保存
        save 60 10000


    下面介绍详细的快照保存过程:

            1.redis 调用 fork,现在有了子进程和父进程。

            2. 父进程继续处理 client 请求,子进程负责将内存内容写入到临时文件。由于 os 的实时复制机制( copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时 os 会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程地址空间内的数据是 fork时刻整个数据库的一个快照。

            3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程中保存快照的,由于 redis 是用一个主线程来处理所有 client 的请求,这种方式会阻塞所有client 请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步变更数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘 io 操作,可能会严重影响性能。


           二)、AOF方式

            由于快照方式是在一定间隔时间做一次的,所以如果 redis 意外 down 掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话,可以采用 aof 持久化方式。下面介绍 Append-only file:aof 比快照方式有更好的持久化性,是由于在使用 aof 持久化方式时,redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于 os 会在内核中缓存 write 做的修改,所以可能不是立即写到磁盘上。这样 aof 方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。有三种方式如下(默认是:每秒 fsync 一次)


        appendonly yes //启用 aof 持久化方式
        # appendfsync always //收到写命令就立即写入磁盘,最慢,但是保证完全的持久化
        appendfsync everysec //每秒钟写入磁盘一次,在性能和持久化方面做了很好的折中
        # appendfsync no //完全依赖 os,性能最好,持久化没保证

            aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr test命令 100 次,文件中必须保存全部的 100 条命令,其实有 99 条都是多余的。因为要恢复数据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。 redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件。

    转载于:https://www.cnblogs.com/wujifu/p/11564897.html

    展开全文
  • Redis 主从、哨兵和集群 区别

    千次阅读 2019-03-06 13:39:50
    Redis 复制功能的几个重要方面: 一个主服务器可以有多个从服务器。 不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构。 复制功能不会阻塞主服务器: 即使有...

    主从模式 (master-slave)

    在这里插入图片描述
    备份数据、负载均衡,一个Master可以有多个Slaves。
    主从模式强调 数据备份,读写分离等

    Redis 复制功能的几个重要方面:

    1. 一个主服务器可以有多个从服务器。
    2. 不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构。
    3. 复制功能不会阻塞主服务器: 即使有一个或多个从服务器正在进行初次同步, 主服务器也可以继续处理命令请求。
    4. 复制功能也不会阻塞从服务器: 只要在 redis.conf 文件中进行了相应的设置, 即使从服务器正在进行初次同步, 服务器也可以使用旧版本的数据集来处理命令查询。
      不过, 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内, 连接请求会被阻塞。
      你还可以配置从服务器, 让它在与主服务器之间的连接断开时, 向客户端发送一个错误。
    5. 复制功能可以单纯地用于数据冗余(data redundancy), 也可以通过让多个从服务器处理只读命令请求来提升扩展性(scalability): 比如说, 繁重的 SORT 命令可以交给附属节点去运行。
    6. 可以通过复制功能来让主服务器免于执行持久化操作: 只要关闭主服务器的持久化功能, 然后由从服务器去执行持久化操作即可。

    哨兵模式 (sentinel)

    在这里插入图片描述
    sentinel发现master挂了后,就会从slave中重新选举一个master。
    哨兵模式强调高可用

    Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:

    监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

    提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

    自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

    客户端中不会记录redis的地址(某个IP),而是记录sentinel的地址,这样我们可以直接从sentinel获取的redis地址,因为sentinel会对所有的master、slave进行监控,它是知道到底谁才是真正的master的,例如我们故障转移,这时候对于sentinel来说,master是变了的,然后通知客户端。而客户端根本不用关心到底谁才是真正的master,只关心sentinel告知的master。

    集群模式 (cluster)

    在这里插入图片描述
    cluster是为了解决单机Redis容量有限的问题,将数据按一定的规则分配到多台机器。

    集群模式提高并发量。


    Redis持久化

    redis支持两种方式的持久化,可以单独使用或者结合起来使用。
    1、第一种:RDB方式redis默认的持久化方式(快照)
    2、第二种:AOF方式(日志追加)

    RDB快照模式(snapshot):

    save 900 1  //900秒内如果超过1个key被修改,则发起快照保存
    save 300 10 //300秒内容如超过10个key被修改,则发起快照保存
    save 60 10000  //(这3个选项都屏蔽,则rdb禁用)
    
    stop-writes-on-bgsave-error yes  // 后台备份进程出错时,主进程停不停止写入
    rdbcompression yes      // 导出的rdb文件是否压缩
    Rdbchecksum   yes       //导入rbd恢复时数据时,要不要检验rdb的完整性
    dbfilename dump.rdb     //导出来的rdb文件名
    dir /var/lib/redis/     //rdb的放置路径
    

    AOF日志模式:

    appendonly yes              //启用aof持久化方式
    # appendfsync always        //每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
    appendfsync everysec        //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐
    # appendfsync no            //完全依赖os,性能最好,持久化没保证(操作系统自身的同步)
    no-appendfsync-on-rewrite  yes   //正在导出rdb快照的过程中,要不要停止同步aof
    auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写
    auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写
    

    注意:
    1、AOF和RDB同时存在的时候,优先使用AOF恢复数据,因为AOF保存的数据集更完整;
    2、AOF和RDB恢复的时候,RDB更快,直接拷贝数据,AOF还要执行语句;
    3、建议同时使用AOF和RDB

    参考资料:
    Redis主从同步,哨兵
    redis sentinel架构详解

    展开全文
  • AOF机制服务尽量少中断:增加副本冗余主从模式Redis提供了主从库模式,增加冗余的副本来提高Redis集群的高可靠性。主从库之间采用读写分离的方式,写请求只能在主库,读请求在主从库都可以完成。读操作:主库、从库...

    主从库模式

    Redis的高可靠性主要包括两方面:

    • 数据尽量少丢失:RDB & AOF机制

    • 服务尽量少中断:增加副本冗余

    主从模式

    Redis提供了主从库模式,增加冗余的副本来提高Redis集群的高可靠性。主从库之间采用读写分离的方式,写请求只能在主库,读请求在主从库都可以完成。

    • 读操作:主库、从库

    • 写操作:主库 --> 主库写完后同步从库

    9631a97b1a848939234ff3bb085f339d.png

    写请求为什么只能在主库上,若从库和主库上都可以进行读写会发生什么?

    • 1. 若有3个写请求先后都是对key1进行操作,并且分别请求到了不同实例上,对应修改的值分别为v1,v2,v3,那么key1对应的值在每个实例上都是不一致的。读数据时,可能会读到旧的值。

    • 2. 若要保持这个数据在3个实例上都是一致的,旧要涉及到加锁、实例间协商是否完成修改等一系列操作,但这会带来巨额的开销,得不偿失。

    主从库之间是如何同步的

    全量同步:当从库是第一次建立连接并开始同步,该种情况下的同步如下图:

    3f2431021a654245cf49936f2abf07e6.png

    • 从库和主库建立起连接,并告诉主库即将进行同步,主库确认回复后,主从库间就可以开始同步了。首先,从库给主库发送 psync 命令,表示要进行数据同步,主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。
      (1)runID,是每个 Redis 实例启动时都会自动生成的一个随机 ID,用来唯一标记这个实例。当从库和主库第一次复制时,因为不知道主库的 runID,所以将 runID 设为“?”。
      (2)offset,此时设为 -1,表示第一次复制。

    • FULLRESYNC 响应表示第一次复制采用的全量复制,也就是说,主库会把当前所有的数据都复制给从库。在第二阶段,主库将所有数据同步给从库。从库收到数据后,在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。为了保证主从库的数据一致性,主库会在内存中用专门的 replication buffer,记录 RDB 文件生成后收到的所有写操作。

    • 主库会把第二阶段执行过程中新收到的写命令,再发送给从库。具体的操作是,当主库完成 RDB 文件发送后,就会把此时 replication buffer 中的修改操作发给从库,从库再重新执行这些操作。这样一来,主从库就实现同步了。

    增量同步:

    Redis增量复制是指replica初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

    Redis的主节点创建和维护一个环形缓冲复制队列(即repl_backlog_buffer),从节点部分复制(增量复制)的数据均来自于repl_backlog_buffer。主节点只有一个repl_backlog_buffer,所有从节点共享。

    主-从-从模式减少主库全量同步时的压力

    主从库模式中,所有的从库都是和主库连接,所有的全量复制也都是和主库进行的。现在,我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力,以级联的方式分散到从库上。如下图:

    c6152e7608d25f64d4ac5fe1757f58e9.png

    主从库网络中断怎么办

    Redis的主节点创建和维护一个环形缓冲复制队列(即repl_backlog_buffer),从节点部分复制(增量复制)的数据均来自于repl_backlog_buffer。主节点只有一个repl_backlog_buffer,所有从节点共享。

    当主从库断连后,主库每次都会把收到的写操作命令,写入 replication buffer,同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。主库会记录自己写到的位置,从库则会记录自己已经读到的位置。主库来的偏移量是master_repl_offset,对从库来说从库已复制的偏移量是slave_repl_offset,正常情况下,这两个偏移量基本相等。

    主从库的连接恢复之后,从库首先会给主库发送 psync 命令,并把自己当前的 slave_repl_offset 发给主库,主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。在网络断连阶段,主库可能会收到新的写操作命令,所以,一般来说,master_repl_offset 会大于 slave_repl_offset。此时,主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。

    哨兵

    哨兵其实就是一个运行在特殊模式下的 Redis 进程,主从库实例运行的同时,它也在运行。哨兵主要负责的就是三个任务:监控、选主(选择主库)和通知,哨兵节点其实就是一个特殊的Redis实例节点。

    • 监控:判断主从库下线

    • 选主:选出新主库

    • 通知:让从库与主库同步,通知客户端与主库连接

    1c678258424f1da6a98455e67ef197b9.png

    哨兵与没一个主库和从库相连接,并且哨兵节点之间行成集群。

    6c30e78ded16be75ffe83a2bd53bcfdf.png

    监控

    哨兵与没一个Redis节点相连接并通过PING命令检测它自己和主、从库的网络连接情况,用来判断实例的状态。没一个Redis节点的状态可以分为”主观下线“和”客观下线“。

    如果检测的是从库,那么,哨兵简单地把它标记为“主观下线”就行了,因为从库的下线影响一般不太大,集群的对外服务不会间断。

    如果检测的是主库,那么,哨兵还不能简单地把它标记为“主观下线”,开启主从切换。因为很有可能存在这么一个情况:那就是哨兵误判了,其实主库并没有故障。可是,一旦启动了主从切换,后续的选主和通知操作都会带来额外的计算和通信开销。

    在判断主库是否下线时,不能由一个哨兵说了算,只有大多数的哨兵实例,都判断主库已经“主观下线”了,主库才会被标记为“客观下线”,这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是:少数服从多数。同时,这会进一步触发哨兵开始主从切换流程。

    选主

    当主库挂了以后,哨兵会在从库中进行选主,选主主要包括以下三个原则。

    • 首先,优先级最高的从库得分高。

    • 其次,和旧主库同步程度最接近的从库得分高。

    • 最后,ID 号小的从库得分高。

    用户可以通过 slave-priority 配置项,给不同的从库设置不同优先级。比如,你有两个从库,它们的内存大小不一样,你可以手动给内存大的实例设置一个高优先级。在选主时,哨兵会给优先级高的从库打高分,如果有一个从库优先级最高,那么它就是新主库了。如果从库的优先级都一样,那么哨兵开始进行第二个原则判断。

    这个规则的依据是,如果选择和旧主库同步最接近的那个从库作为主库,那么,这个新主库上就有最新的数据。主从库同步时有个命令传播的过程。在这个过程中,主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置,而从库会用 slave_repl_offset 这个值记录当前的复制进度。

    每个实例都会有一个 ID,这个 ID 就类似于这里的从库的编号。目前,Redis 在选主库时,有一个默认的规定:在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。

    分片集群

    当数据容量越来越大时,如Redis集群的数据量有5G增长到了25G,那么需要考虑集群的扩容问题,在扩容时一般有两种方案:

    • 纵向扩展:升级单个 Redis 实例的资源配置,包括增加内存容量、增加磁盘容量、使用更高配置的 CPU。将磁盘容量扩展到50G
      简单直接,但是增加了硬件和成本的限制、当使用 RDB 对数据进行持久化时,如果数据量增加,需要的内存也会增加,主线程 fork 子进程时就可能会阻塞

    • 横向扩展:横向增加当前 Redis 实例的个数,就像下图中,原来使用 1 个 *GB 内存、10GB 磁盘的实例,现在使用三个相同配置的实例。

    05e87e4446e8b23c213a51b85fac262b.png

    分片和实例的对应分布关系

    在分片集群中,数据需要分布在不同实例上,那么,数据和实例之间如何对应呢?这就和接下来我要讲的 Redis Cluster 方案有关了。不过,我们要先弄明白切片集群和 Redis Cluster 的联系与区别。

    Redis Cluster 方案采用哈希槽(Hash Slot,接下来我会直接称之为 Slot),来处理数据和实例之间的映射关系。在 Redis Cluster 方案中,一个切片集群共有 16384 个哈希槽,这些哈希槽类似于数据分区,每个键值对都会根据它的 key,被映射到一个哈希槽中。

    • 首先根据键值对的 key,按照CRC16 算法计算一个 16 bit 的值;

    • 然后,再用这个 16bit 值对 16384 取模,得到 0~16383 范围内的模数,每个模数代表一个相应编号的哈希槽。

    以只有五个槽为例,展示,数据、哈希槽、实例这三者的映射分布情况,如下图:

    be7f16d2f42c421923625692ee15a693.png

    客户端如何定位数据

    客户端和集群实例建立连接后,实例就会把哈希槽的分配信息发给客户端。但是,在集群刚刚创建的时候,每个实例只知道自己被分配了哪些哈希槽,是不知道其他实例拥有的哈希槽信息的。那么,客户端为什么可以在访问任何一个实例时,都能获得所有的哈希槽信息呢?这是因为,Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例,来完成哈希槽分配信息的扩散。当实例之间相互连接后,每个实例就有所有哈希槽的映射关系了。客户端收到哈希槽信息后,会把哈希槽信息缓存在本地。当客户端请求键值对时,会先计算键所对应的哈希槽,然后就可以给相应的实例发送请求了。

    实例和哈希槽的对应关系并不是一成不变的,最常见的变化有两个:

    • 在集群中,实例有新增或删除,Redis 需要重新分配哈希槽

    • 为了负载均衡,Redis 需要把哈希槽在所有实例上重新分布一遍

    Redis Cluster 方案提供了一种重定向机制,所谓的“重定向”,就是指,客户端给一个实例发送数据读写操作时,这个实例上并没有相应的数据,客户端要再给一个新实例发送操作命令。

    f1ab2f168be9ebfc711ee7aa639cbf82.png

    需要注意的是,在上图中,当客户端给实例 2 发送命令时,Slot 2 中的数据已经全部迁移到了实例 3。在实际应用时,如果 Slot 2 中的数据比较多,就可能会出现一种情况:客户端向实例 2 发送请求,但此时,Slot 2 中的数据只有一部分迁移到了实例 3,还有部分数据没有迁移。在这种迁移部分完成的情况下,客户端就会收到一条 ASK 报错信息。

    这个结果中的 ASK 命令就表示,客户端请求的键值对所在的哈希槽 13320,在实例3上,但是这个哈希槽正在迁移。此时,客户端需要先给 实例3这个实例发送一个 ASKING 命令。这个命令的意思是,让这个实例允许执行客户端接下来发送的命令。然后,客户端再向这个实例发送 GET 命令,以读取数据。

    eedd9467462baf1e05c7b89f095262cc.png

    在下图中,Slot 2 正在从实例 2 往实例 3 迁移,key1 和 key2 已经迁移过去,key3 和 key4 还在实例 2。客户端向实例 2 请求 key2 后,就会收到实例 2 返回的 ASK 命令。ASK 命令表示两层含义:第一,表明 Slot 数据还在迁移中;第二,ASK 命令把客户端所请求数据的最新实例地址返回给客户端,此时,客户端需要给实例 3 发送 ASKING 命令,然后再发送操作命令。ASK 命令并不会更新客户端缓存的哈希槽分配信息。


    作者:买个橘子
    链接:https://juejin.im/post/6894048481422344199

    展开全文
  • 前一篇文章谈了Redis高并发快的3个...这时候就需要哨兵和复制。哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。复制(Replication):则是负责让一个Redis服务器可以配备多个...
  • 这时候就需要哨兵和复制。 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis正是利用这两...
  • Redis哨兵、复制、集群的设计原理,以及区别 知识点标签:高可用、完整备份、哨兵和复制、集群 1.面试题分析 谈到Redis服务器的高可用,如何保证备份的机器是原始服务器的完整备份呢?这时候就需要哨兵和复制。 1....
  • 一、主从复制1 概念Redis多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境...
  • 一、前言 说到Redis服务器的高可用,如何保证备份的及其是原始服务器的完整备份呢?这时候就需要哨兵和复制 1、**哨兵(Sentinel)
  • 这时候就需要哨兵和复制。哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。 复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis正是利用这两个...
  • 这时候就需要哨兵和复制。哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。Redis正是利用这两个...
  • 这时候就需要哨兵和复制。 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。 复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis正是...
  • 哨兵模式强调高可用Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:监控(Monitoring): Sentinel 会不断地检查你的主服务器从服务器是否运作正常。提醒(Noti...
  • 哨兵 1.作用:监控主数据库从数据库是否正常运行 2.Sentinel 的任务: a.监控 b.提醒 c.故障转移 集群 目的:为了解决单节点容量问题
  • 前一篇文章谈了Redis高并发快的3个...这时候就需要哨兵和复制。哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。复制(Replication):则是负责让一个Redis服务器可以配备多个...
  • 这时候就需要哨兵和复制。 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。 复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。 Redis正是...
  • 这时候就需要哨兵和复制。 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能。 复制(Replication):则是负责让一个Redis服务器可以配备多个备份的服务器。 .
  • 1.Redis服务器的高可用,这时候就需要哨兵和复制 (1)哨兵(Sentinel): <1>可以管理多个Redis服务器,提供了监控,提醒以及自动的故障转移的功能 <2>哨兵是Redis集群架构中非常重要的一个组件 <3...
  • 集群分片 比如 5主5从,也就是说 数据过来之后会均匀的分配到5台服务器上面,5台服务器上面的数据是不同的,但是每...关于哨兵模式,就类似于zookeeper的选举模式一样,5个服务器需要一个管理的主机,他们需要选举出...
  • 文章目录前期准备哨兵模式和集群模式的区别单机模式主从模式哨兵模式集群模式 前期准备 centos 7 系统 docker 拉取镜像并且改名 docker pull registry.cn-hangzhou.aliyuncs.com/sasiki/redis:v5 docker tag...
  • Redis和Memcache的区别 储存方式不同:Redis数据储存是内存+磁盘,Memcached是储存在内存 数据类型不同:Redis支持五种数据类型,而Memcached只支持一种 数据大小不同:Redis可以最大储存521mb,Memcached最大只能...
  • 一、Redis哨兵模式在SpringBoot中的使用哨兵模式变化的就是配置信息;其他的单机版的没有区别。spring: redis: # redis集群的密码 password: 123456 # 超时时间,单位毫秒 timeout: 3000 # 数据库编号 database: 0...

空空如也

空空如也

1 2 3 4 5
收藏数 97
精华内容 38
关键字:

redis哨兵和集群区别

redis 订阅