Redis高可用定义

在web服务器中，高可用代表服务器可以正常访问的时间，一般使用百分比来衡量多长时间内可以提供正常服务
但是在redis中，高可用的定义还要更广泛一点，除了提供正常的服务（如主从分离、快速灾变技术），还要考虑到数据容量的扩展，数据安全不丢失等。

Redis实现高可用的技术

分为四种
持久化
主从复制
哨兵
集群（cluster）

持久化

持久化是最简单的高可用方法，有时甚至不被承认是高可用方法，主要作用是数据备份，即将数据存储到硬盘，保证数据不会因为进程退出而丢失

主从复制

主从复制时高可用Redis的基础，哨兵和集群都是在主从复制的基础上实现的。主从复制主要是实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
缺点：故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制，比较吃资源

哨兵

在主从复制的基础上，哨兵实现了自动化的故障恢复
缺点：写操作无法负载均衡，存储能力受到单机限制

集群（cluster）（分布式）

Redis通过集群的解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案

Redis持久化

持久化的功能：redis是内存数据库，数据都是存储在内存之中的，为了避免服务器断电原因导致的redis进程异常退出后数据的永久丢失，需要定期将Redis中的数据以某种形式或命令指令从内存保存到硬盘之中，当下次Redis重启时，利用持久化文件实现数据恢复，除此之外，为了进行灾备备份，可以将持久化文件拷贝到一个远程位置（NFS）。

Redis提供持久化的两种方式、

1、RDB持久化：原理是将Redis在内存中的数据库记录定时保存在磁盘上，相当于做了个快照
2、AOF持久化：原理是将Redis的操作日志以追加的方式写入文件，类似Mysql中的binlog（基于日志持久化的方式）

由于AOF持久化的实时性更好，因此AOF是主流的持久化方式，RDB持久化基本都会开启（用于集群）

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（因此也被传给你做快照持久化），它使用二进制压缩存储，保存文件的后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据。

总结⭐⭐
①周期性1-10秒(会进行一定的限制，第二周期过于短暂会导致数据同步冗余的情况)
②保存形式:二进制压缩存储( .rdb)
③可用于恢复，redis 重启后，缓存中的数据会清空，此时redis中的数据就是基于. rdb文件进行恢复的

[root@localhost ~]# vim /etc/redis/6379.conf251 rdbchecksum yes //开启RDB文件压缩254 dbfilename dump.rdb  //指定RDB文件名264 dir /var/lib/redis/6379   //指定RDB和AOF所在目录

触发条件
1、手动触发
save命令和bgsave命令都可以生成RDB文件
save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。
而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程) 则继续处理请求。
bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用
往往生产环境bgsave 依然不允许轻易使用

[root@localhost ~]# redis-cli   //进入数据库
127.0.0.1:6379> bgsave      //手动执行
Background saving started
127.0.0.1:6379>
[root@localhost ~]# ls /var/lib/redis/6379/
dump.rdb     //RDB文件

2、自动触发
在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化

save m n 自动触发最常见的情况是在配置文件中通过save m n，代表当m秒内发生n次变化时，会触发bgsave.

[root@localhost ~]# vim /etc/redis/6379.conf219 save 900 1      //900秒内至少发生一次变化，执行bgsave220 save 300 10      //300秒内至少发生10次变化，执行bgsave221 save 60 10000       //60秒内至少发生10000次变化，执行bgsave242 rdbcompression yes   //是否开启RDB文件压缩254 dbfilename dump.rdb   //指定RDB文件名264 dir /var/lib/redis/6379    //指定RDB文件和AOF文件所在的目录

其他自动触发机制
除了save m n以外，还有一些其他情况会触发bgsave:
●在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。
●执行shutdown命令时，自动执行rdb持久化。

执行流程

(1) Redis父进程首先判断:当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
(2) 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
(3) 父进程fork后，bgsave 命令返回”Background saving started" 信息并不再阻塞父进程，并可以响应其他命令
(4) 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
(5) 子进程发送信号给父进程表示完成，父进程更新统计信息

启动时加载

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据;仅当A0F关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。
① RDB和AOF以优先级而言AOF》RDB .
②在服务器时，仅档AOF功能关闭，才会载入RDB文件
③启动过程中进行持久化文件的检测校验，若损坏，则打印错误，启动失败。

AOF持久化

RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操
作不会记录;当Redis重启时优先执行AOF文件中的命令来恢复数据。
与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

[root@localhost ~]# vim /etc/redis/6379.conf700 appendonly yes          //手动开启AOF701 702 # The name of the append only file (default: "appendonly.aof")703 704 appendfilename "appendonly.aof"  //指定AOF文件名796 aof-load-truncated yes        //忽略此条可能出现问题[root@localhost ~]# vim /etc/redis/6379.conf
[root@localhost ~]# /etc/init.d/redis_6379 restart   //重启使配置文件生效

执行流程

由于需要记录redis的每条写命令，因此AOF不需要触发。
●命令追加(append) :将Redis的写命令追加到缓冲区aof_ buf; (为了尽量不因为持久化而影响redis性能)
●文件写入(write)和文件同步(sync) :根据不同的同步策略将aof_ buf中的内容同步到硬盘;
●文件重写(rewrite): 定期重写AOF文件，达到压缩的目的。

启动时加载

当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据;只有当AOF关闭时，才会载入RDB文件恢复数据。
当A0F开启，但AOF文件不存在时，即使RDB文件存在也不会加载。
Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load- truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。
aof-load-truncated参数默认是开启的。

RDB和AOF的优缺点

一、RDB持久化(以二进制压缩的方式保存的文件)
优点：RDB文件紧凑，体积小，网络传输快，适合全量复制;恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。( 和aof同步阻塞)
缺点： RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来I0压力。
二、AOF持久化
优点：与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，
缺点：是文件大、恢复速度慢、对性能影响大。
对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。
AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的I0压力问题。相对来说，由于AOF向硬盘中写数据的频率.
更高，因此对Redis主进程性能的影响会更大。.

Redis集群三种模式

1、主从复制：redis高可用的基础，实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。
2、哨兵模式：基于主从复制模式，实现了自动化的故障恢复
缺陷：写操作无法负载均衡、存储能力受到单机的限制。
3、cluster集群模式：通过Redis集群解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

Redis集群（cluster）

①redis是一个开源的key-value存储系统，受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式，在3.0版本及以后才支持集群redis集群采用P2P模式，是完全去中心化/无中心化的，不存在中心节点或者代理节点;
中心化去中心化
⭐⭐有状态无状态(K8S管理手段)
无状态:加入集群之后集群认为是普通节点，没有明确的角色定位
有状态:加入集群之后有定位要求(主或从角色)，有明确的角色定位

②为了实现集群的高可用，即判新节点是否健康(能否正常使用)，redis-cluster有一个投票容错机制:
如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了(fail)。这是判断节点是否挂了的方法:
判断集群是否正常:
如果集群中任意一一个节点挂了，而且该节点没有从节点(备份节点)，那么这个集群就捏了。这是判断集群是否挂了的方法
那么为什么任意一个节点挂了(没有从节点)这个集群就挂了:
#PS:
因为集群(cluster) 内置了16384个slot (哈希槽)存储位，并且把所有的redis物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个redis节点(集群模式)。
当需要在Redis集群存放一个数据(key-value)时，redis 会先对这个key进行crc16算法，然后得到一个结果再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。

Redis安装部署

准备三台机器
同时安装redis

hostname	ip
master	192.168.59.129
slave1	192.168.59.128
slave2	192.168.59.130

安装依赖包

 yum -y install gcc gcc-c++ make

从网上一键式下载redis

cd /opt
[root@slave1 opt]# wget -P /opt http://download.redis.io/releases/redis-5.0.9.tar.gz

解压、编译安装

tar -xzvf redis-5.0.9.tar.gz[root@master opt]# cd redis-5.0.9/
[root@slave1 redis-5.0.9]# make && make PREFIX=/usr/local/redis install

设置配置项

[root@master redis-5.0.9]# cd utils/
[root@slave1 utils]# ./install_server.sh

优化管理路径

ln -s /usr/local/redis/bin/* /usr/local/bin/

1、主从复制

通过持久化功能，redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据，但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务，为此，redis提供了复制(replication)功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
在复制的概念中，数据库分为两类，一类是主数据库(master)，另一-类是从数据(slave)。主数据可以进行读写操作，当写操做导致数据变化时自动把数据同步给从数据库，而从数据库一般是只读的，并接收主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库
2、主从复制流程[图1]
①若启动一个Slave机器进程，则它会向Master机器发送一个"sync_ command"命令，请求同步连接
②无论是第一.次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照(RDB)保存到
数据文件中(执行rdb操作)，同时Master还会记录修改数据的所有命令并缓存在数据文件中。
③后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，Slave端机器将数据
文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave
出现故障导致宕机，则恢复正常后会自动重新连接。.
④Master机器收到slave端机器的连接后，将其完整的数据文件发送给Slave端，如果Mater同时收到多个slave发来的同步请求则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

主从复制部署

master

修改redis配置文件

vim /etc/redis/6379.conf

重启

slave1、2

修改配置

[root@slave1 utils]# vim /etc/redis/6379.conf

重启

验证

在master上看日志
cat /var/log/redis_6379.log
或者
redis-cli info replication

2、哨兵模式（Sentinel）

(1)哨兵模式集群架构
哨兵是Redis集群架构中非常重要的一-个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题
(2)哨兵模式主要功能
①集群监控:负责监控Redis master和slave进程是否正常工作
②消息通知:如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员
③故障转移:如果master node (master角色)挂掉了，会自动转移到slave node.上
④配置中心:如果故障转移发生了，通知client客户端新的master地址
使用一个或者多个哨兵(Sentinel)实例组成的监控管理系统，对redis节点进行监控在主节点出现故障的情况下，
能将从节点中的一一个从节点角色升级为主节点，进行故障转移，保证系统的可用性。

哨兵监控整个过程

①首先主节点的信息是配置在哨兵(Sentinel)的配置文件中
②哨兵节点会和配置的主节点建立起两条连接：命令连接和订阅连接
PS:Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息，订阅者(sub) 接收消息。.
MQ消息代理/队列
③哨兵会通过命令连接每10s发送一次INF0命令，通过INFO命令，主节点会返回自己的run id和自己的从节点信息告诉哨兵
④哨兵会对这些从节点也建立两条连接：命令连接和订阅连接
⑤哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息:
run id(redis服务器id)
role (职能)
从服务器的复制偏移量offset
其他
⑥通过命令连接向服务器的sent inel:hello频道发送一条消息，内容包括自己的ip端口、run id、配置(后续投票的时候会用到)等
⑦通过订阅连接对服务器的sentinel:hello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到
⑧解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来
⑨向观察到的其他的哨兵节点建立命令连接—没有订阅连接

①哨兵之间相互进行命令连接，目的为了在同一频道进行信息共享和监控
②哨兵们向master发送命令连接和订阅连接(周期性)
③哨兵10/s向master发送info R-M会回应哨兵本节点的信息状态+从节点的位置
④哨兵收到回复之后，知晓R-S01 R-S02的位置
⑤然后再向slaves发送命令连接和订阅连接(周期性) ,以达到监控整个集群的目的

哨兵模式下的故障迁移

①主观下线
哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/L0ADING/MASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI S_ DOWN主观下线
②客观下线
当一个哨兵节点发现主节点处于主观下线状态时，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr
③ master选举
在认为主节点客观下线的情况下，哨兵节点节点间会发起一次选举，命令为:SENTINEL is-master-down-by-addr，只是runid这次会将自己的runid带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为le
acer的情况下，会有该leader对故障进行迁移
④故障转移
###在从节点中挑选出新的主节点
通讯正常
优先级排序.
优先级相同时选择offset最大的
##将该节点设置成新的主节点SLAVEOF no one, 并确保在后续的INFO命令时该节点返回状态为master
##將其他的从节点设置成从新的主节点复制，SLAVEOF命令
#将旧的主节点变成新的主节点的从节点
PS:优缺点
#优点:
高可用，哨兵模式是基于主从模式的，所有主从模式的优点，哨兵模式可以简单的检测和实现故障自动切换，
系统更健壮，可用性更高
#缺点:
redis比较难支持在线扩容，在群集容量达到上限时在线扩容会变得很复杂

哨兵部署

三台同步（生产环境下，哨兵不在redis服务器上做）

[root@master utils]# cd /opt/redis-5.0.9/
[root@master redis-5.0.9]# vim sentinel.conf  #修改哨兵配置文件

启动

[root@master redis-5.0.9]# redis-sentinel sentinel.conf &

查看哨兵信息

模拟故障
在master上实时查看

在master上杀死redis-server

查看日志

[root@master redis-5.0.9]# cat /var/log/sentinel.log

3、群集模式（cluster）

redis的哨兵模式基本已经可以实现高可用、读写分离，但是在这种模式每台redis服务器都存储相同的数据，很浪费内存资源，所以在redis3.0.上加入了Cluster群集模式，实现了redis的分布式存储，也京是说每台redis节点存储着不同的内容根据官方推荐，集群部署至少要3台以上的master节点，最好使用3主3从六个节点的模式。
Cluster群集由多个redis服务器组成的分布式网络服务群集，群集之中有多个master主节点，每一个主节点都可读可写，节点之间会相互通信，两两相连，redis群集无中心节点.
在redis-Cluster群集中，可以给每个-一个主节点添加从节点，主节点和从节点直接尊循主从模型的特性，当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能
redis-cluster的故障转移:redis群集的主机节点内置了类似redissentinel的节点故障检测和自动故障转移功能，当群集中的某个主节点下线时，群集中的其他在线主节点会注意到这一一点，并且对已经下线的主节点进行故障转移
集群进行故障转移的方法和redis sentinel进行故障转移的方法基本-样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以群集不必另外使用redis sentinel

主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制
1作用
(1) 数据分区（分布式）
数据分区(或称数据分片)是集群最核心的功能
集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加，另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及
例如，如果单机内存太大，bgsave 和bgrewriteaof的fork
操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出
(2)高可用
集群支持主从复制和主节点的自动故障转移(与哨兵类似)，当任意节点发送故障时，集群仍然可以对外提供服务
(3) 数据分片
Redis集群引入了哈希槽的概念，有16384 个哈希槽(编号0~16383)
集群的每个节点负责-部分哈希槽，每个Key 通过CRC16校验后对16384
取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
以3个节点组成的集群为例:
节点A包含0~5469号的哈希槽
节点B包含.5461~10922 号的哈希槽
节点C包含10923~16383 号的哈希槽

搭建cluster集群

实验环境

三主
192.168.59.129
192.168.59.128
192.168.59.130
三从
192.168.59.131
192.168.59.132
192.168.59.133

安装redis

[root@localhost opt]# tar -xzf redis-5.0.7.tar.gz
[root@localhost opt]# cd redis-5.0.7/
[root@cluster01 redis-5.0.7]# make && make prefix=/usr/local/redis install
[root@localhost redis-5.0.7]# cd utils/
[root@cluster01 utils]# ./install_server.sh
一直回车  直到出现Please select the redis executable path [/usr/local/bin/redis-server]，手动修改为“/usr/local/redis/bin/redis-server

路径优化

ln -s /usr/local/redis/bin/* /usr/local/bin/

创建6个节点的工作目录

[root@cluster01 utils]# cd /etc/redis/
[root@cluster01 redis]# mkdir -p redis-cluster/redis600{1..6}

复制redis配置文件

[root@cluster01 redis]# vim /opt/redis.sh
#!/bin/bash
for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
donechmod +x /opt/redis.sh
[root@cluster01 redis-5.0.7]# bash /opt/redis.sh

修改配置文件

[root@cluster01 ~]# vim /etc/redis/redis-cluster/redis6001/redis.conf
bind 127.0.0.1  //69行，注释掉bind项或不修改，默认监听所有网卡
protected-mode no   //88行，修改，关闭保护模式
port 6001   //92行，修改，redis监听端口，
daemonize yes   //136行，开启守护进程，以独立进程启动
appendonly yes  //700行，修改，开启AOF持久化
cluster-enabled yes     //832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf     //840行，取消注释，群集名称文件设置
cluster-node-timeout 15000      //846行，取消注释群集超时时间设置

对其他五个操作一样只要把端口改一下就可以了

一直到6006

启动服务

编写启动脚本
vim /opt/redis.start
#!/bin/bash
for i in {1..6}
docd /etc/redis/redis-cluster/redis600$iredis-server redis.conf
donechmod +x /opt/redis.start
sh /opt/redis.start

加入集群

[root@localhost redis-cluster]#  redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:6005 to 127.0.0.1:6001
Adding replica 127.0.0.1:6006 to 127.0.0.1:6002
Adding replica 127.0.0.1:6004 to 127.0.0.1:6003
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 98a50ddf7eb92870b1d315552a5bd9a94ff675c2 127.0.0.1:6001slots:[0-5460] (5461 slots) master
M: 389661aa7b6a5eb84a377a59dfaf6c2cdb5782ad 127.0.0.1:6002slots:[5461-10922] (5462 slots) master
M: a2d490d0825b84f3e88a97cbd02edbaf091d6736 127.0.0.1:6003slots:[10923-16383] (5461 slots) master
S: 9909ac7560d3983e33a242242592fbcfc2ddb2f7 127.0.0.1:6004replicates 389661aa7b6a5eb84a377a59dfaf6c2cdb5782ad
S: 859fdb023ccad099f8e0ea7ce62a7a0ab255e712 127.0.0.1:6005replicates a2d490d0825b84f3e88a97cbd02edbaf091d6736
S: 8b0827a69aba4220234ad5fe9f40880498871ed6 127.0.0.1:6006replicates 98a50ddf7eb92870b1d315552a5bd9a94ff675c2
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
...
>>> Performing Cluster Check (using node 127.0.0.1:6001)
M: 98a50ddf7eb92870b1d315552a5bd9a94ff675c2 127.0.0.1:6001slots:[0-5460] (5461 slots) master1 additional replica(s)
S: 8b0827a69aba4220234ad5fe9f40880498871ed6 127.0.0.1:6006slots: (0 slots) slavereplicates 98a50ddf7eb92870b1d315552a5bd9a94ff675c2
M: a2d490d0825b84f3e88a97cbd02edbaf091d6736 127.0.0.1:6003slots:[10923-16383] (5461 slots) master1 additional replica(s)
S: 9909ac7560d3983e33a242242592fbcfc2ddb2f7 127.0.0.1:6004slots: (0 slots) slavereplicates 389661aa7b6a5eb84a377a59dfaf6c2cdb5782ad
M: 389661aa7b6a5eb84a377a59dfaf6c2cdb5782ad 127.0.0.1:6002slots:[5461-10922] (5462 slots) master1 additional replica(s)
S: 859fdb023ccad099f8e0ea7ce62a7a0ab255e712 127.0.0.1:6005slots: (0 slots) slavereplicates a2d490d0825b84f3e88a97cbd02edbaf091d6736
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

查看各个节点对应的哈希槽

[root@localhost redis-cluster]# redis-cli -p 6001 -c  # -c表示节点之间可以切换
127.0.0.1:6001> cluster slots   #查看给节点对应的哈希槽
1) 1) (integer) 02) (integer) 54603) 1) "127.0.0.1"2) (integer) 60013) "98a50ddf7eb92870b1d315552a5bd9a94ff675c2"4) 1) "127.0.0.1"2) (integer) 60063) "8b0827a69aba4220234ad5fe9f40880498871ed6"
2) 1) (integer) 109232) (integer) 163833) 1) "127.0.0.1"2) (integer) 60033) "a2d490d0825b84f3e88a97cbd02edbaf091d6736"4) 1) "127.0.0.1"2) (integer) 60053) "859fdb023ccad099f8e0ea7ce62a7a0ab255e712"
3) 1) (integer) 54612) (integer) 109223) 1) "127.0.0.1"2) (integer) 60023) "389661aa7b6a5eb84a377a59dfaf6c2cdb5782ad"4) 1) "127.0.0.1"2) (integer) 60043) "9909ac7560d3983e33a242242592fbcfc2ddb2f7"
127.0.0.1:6001>

** 测试集群**

[root@localhost redis-cluster]# redis-cli -p 6003 -c
127.0.0.1:6003> set dyf 123
OK
127.0.0.1:6003> get dyf
"123"
127.0.0.1:6003> quit[root@localhost redis-cluster]# redis-cli -p 6002 -c
127.0.0.1:6002> get dyf
-> Redirected to slot [14602] located at 127.0.0.1:6003
"123"
127.0.0.1:6003> cluster keyslot dyf
(integer) 14602

redis 高可用（持久化、主从复制、哨兵、集群）以及集群的三种模式相关推荐

2.redis高可用-持久化-主从复制-哨兵-cluster集群概述与部署，内容依旧多看完直接通透！
文章目录一,Redis 高可用 1.持久化 2.主从复制 3.哨兵 4.集群(cluster) 二,Redis 持久化方式 1.持久化的功能 2.持久化的方式三, RDB 持久化 1.触发条件 2 ...
带哨兵节点的链_深入学习Redis高可用架构：哨兵原理及实践
原标题:深入学习Redis高可用架构:哨兵原理及实践 " 在上篇文章<深入学习 Redis 高可用的基石:主从复制>中曾提到,Redis 主从复制的作用有数据热备.负载均衡.故障 ...
Redis高可用之主从复制、哨兵、cluster集群
一 Redis高可用 1.什么是高可用在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.9%.99.99%.99.999%等等). 高可用的计算公 ...
Redis高可用：主从复制及哨兵模式
目录主从复制作用复制原理使用的方式哨兵模式主从切换过程 Redis Sentinel的配置文件参考主从复制主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器.前 ...
Redis高可用--持久化
在Web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准实在多长时间内可以提供正常服务(99.9%.99.99%.99.999%等等). 但是在Redis语境中,高可用的含义似乎要宽泛一些,除 ...
深入学习Redis高可用架构：哨兵原理及实践
Redis 主从复制的作用有数据热备.负载均衡.故障恢复等:但主从复制存在的一个问题是故障恢复无法自动化. 本文将要介绍的哨兵,它基于 Redis 主从复制,主要作用便是解决主节点故障恢复的自动化问题 ...
Mysql主从和redis集群哪个好_Redis的三种模式：主从、哨兵、集群
前言 Redis是一个开源的使用ANSI C语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API.普遍用于目前主流的分布式架构系统中,关于redis的详细 ...
深入浅出LVS：企业集群平台负载均衡的三种模式和算法实现
一.LVS集群常见架构图 Load Balancer层:位于整个集群系统的最前端,由一台或多台负载调度器(Director Server)组成.LVS核心模板IPVS就安装在Director Serv ...
Linux Redis 高可用之主从复制
Redis主从复制简介和MySQL主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况.为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多 ...
【Redis】Redis高可用之Sentinel哨兵模式详解（Redis专栏启动）

redis 高可用（持久化、主从复制、哨兵、集群）以及集群的三种模式

Redis高可用定义

Redis实现高可用的技术

持久化

主从复制

哨兵

集群（cluster）（分布式）

Redis持久化

Redis提供持久化的两种方式、

RDB持久化

执行流程

启动时加载

AOF持久化

执行流程

启动时加载

RDB和AOF的优缺点

Redis集群三种模式

Redis集群（cluster）

Redis安装部署

1、主从复制

主从复制部署

master

slave1、2

2、哨兵模式（Sentinel）

哨兵监控整个过程

哨兵模式下的故障迁移

哨兵部署

3、群集模式（cluster）

搭建cluster集群

redis 高可用（持久化、主从复制、哨兵、集群）以及集群的三种模式相关推荐

最新文章

热门文章