目录
- 3.Redis集群
- 3.1 主从复制
- 3.1.1 主从复制简介
- 083-主从复制-主从复制简介
- 084-主从复制-主从复制的作用
- 3.1.2 主从复制工作流程
- 085-主从复制-主从复制的三个阶段
- 086-主从复制-工作流程（1）建立连接阶段
- 087-主从复制-搭建主从结构
- 088-主从复制-工作流程（2）数据同步阶段（简）
- 089-主从复制-数据同步阶段注意事项
- 090-主从复制-运行id(runid)
- 091-主从复制-复制缓冲区与偏移量
- 092-主从复制-工作流程（2）数据同步与命令传播阶段（全）
- 093-主从复制-心跳机制与命令传播阶段工作流程
- 3.1.3 主从复制常见问题
- 094-主从复制-常见问题（1）
- 095-主从复制-常见问题（2）
- 096-主从复制-常见问题（3）
- 3.2 哨兵模式
- 3.2.1 哨兵简介
- 097-哨兵-哨兵简介
- 3.2.2 启用哨兵模式
- 098-哨兵-哨兵结构搭建
- 3.2.3 哨兵工作原理
- 099-哨兵-工作原理（1）
- 100-哨兵-工作原理（2）
- 101-哨兵-工作原理（3）
- 3.3 集群
- 3.3.1 集群简介
- 102-集群-集群简介
- 3.3.2 Redis集群结构设计
- 103-集群-集群存储结构设计
- 1.数据存储设计
- 2.集群内部通讯设计
- 3.3.3 cluster集群结构搭建
- 104-集群-cluster集群搭建
- 105-集群-设置与获取数据
- 106-集群-主从下线与主从切换
3.Redis集群
3.1 主从复制
3.1.1 主从复制简介
083-主从复制-主从复制简介
互联网“三高”架构
高并发
高性能
高可用
服务器的可用性：
一年的时间(秒数) - 一年总的宕机时间(秒数)
-------------------------------------- *100% = ？
一年的时间(秒数)
业界可用性目标5个9，即99.999%，即服务器年宕机时长低于315秒，约5.25分钟你的“ Redis"是否高可用
单机redis的风险与问题
问题1机器故障
现象：硬盘故障、系统崩溃
质：数据丢失，很可能对业务造成灾难性打击
结论：基本上会放弃使用 redis
问题2容量瓶颈
现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
本质：穷，硬件条件跟不上
结论：放弃使用 redis
结论:
为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本
保存在不同的服务器上，'连接在一起'，并保证数据是'同步'的。即使有其中一台服务器
宕机，其他服务器依然可以继续提供服务，实现 Redis的高可用，同时实现数据'冗余备份'多台服务器连接方案
多台服务器连接方案：使用这种方式，就可以实现高可用
提供数据方：master
主服务器，主节点，主库
主客户端
接收数据方：slave
从服务器，从节点，从库
从客户端
需要解决的问题
数据同步
核心工作：
master的数据复制到save中
由主计算机向从计算机复制数据，这就是这一章要讲的内容：主从复制主从复制
主从复制即将master中的数据即时、有效的复制到slave中
特征：一个master可以拥有多个slave，一个slave只对应一个master
职责
master：
写数据
执行写操作时，将出现变化的数据自动同步到slave
读数据（可忽略）
slave
读数据
写数据（禁止）084-主从复制-主从复制的作用
高可用集群
多个maste(master集群)，用到了下面的哨兵
主从复制的作用
读写分离：
master写、 slave读，提高服务器的读写负载能力
负载均衡：
基于主从结构，配合读写分离，由slave分担master的负载，并根据需求的变化，改变
slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
故障恢复：
当master出现问题的时候，由slave提供服务，实现快速的故障恢复
数据冗余：
实现数据热备份，是持久化之外的一种数据冗余方式
高可用基石：
基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案3.1.2 主从复制工作流程
085-主从复制-主从复制的三个阶段
主从复制工作流程
总述
主从复制过程大体可以分为3个阶段
建立连接阶段（即准备阶段）
数据同步阶段
命令传播阶段
086-主从复制-工作流程（1）建立连接阶段
主从复制工作流程
阶段一：建立连接阶段
建立s1ave到master的连接，使master能够识别slave，并保存slave端口号建立连接阶段工作流程
步骤1：设置master的地址和端口，保存master信息 //1 2 3
步骤2：建立socket连接 //4
步骤3：发送ping命令(定时器任务) //5 6 检测是否断开连接
步骤4：身份验证 //7 8
步骤5：发送slave端口信息 //9 10
至此，主从连接成功！
最终达到的状态
slave：
保存master的地址和端口
master：
保存slave的端口
总体：
它们之间创建了连接的socket，用它来完成信息的交换
Redis一般不对外提供服务/功能，外界是看不到它的；都是内网访问，所以说即使不加身份验证也没关系087-主从复制-搭建主从结构
主从复制工作流程
主从连接（slave连接master）
方式一：客户端发送命令
slaveof <masterip> <masterport>
方式二：启动服务器参数
redis-server --slaveof <masterip> <masterport>
方式三：服务器配置
slaveof <masterip> <masterport>
slave系统信息
master_link_down_since_seconds
masterhost
masterport
master系统信息
slave_listening_port（多个）主从断开连接
客户端发送命令
slaveof no one授权访问
master'配置文件'设置密码 //在配置文件中设置密码
requirepass <password>
master客户端发送命令设置密码 //master已经启动了，想加密码，就在master它的client中通过指令设置密码
config set requirepass <password>
config get requirepass
//一旦master设置了密码，slave想访问时，slave必须挂上密码
slave客户端发送命令设置密码//指令里加上密码，来获得master的授权
auth <password
slave配置文件设置密码 //配置文件里加上密码，来获得master的授权
auth <password>
启动客户端设置密码 //访问带密码的master时，必须挂上密码，来获得master的授权
redis-cli -a <pas sword>088-主从复制-工作流程（2）数据同步阶段（简）
这个阶段：slave找master要数据，master把数据给它
最终达到的结果：slave与master数据同步主从复制工作流程
阶段二：数据同步阶段工作流程
在s1ave初次连接 master后，复制 master中的所有数据到s1ave
将s1ave的数据库状态更新成 master当前的数据库状态主从复制工作流程
数据同步阶段工作流程 //全量复制+部分复制
步骤1：请求同步数据
步骤2：创建RDB同步数据
步骤3：恢复RDB同步数据
步骤4：请求部分同步数据
步骤5：恢复部分同步数据
至此，数据同步工作完成！
状态
slave：
具有 master端全部数据，包含RDB过程接收的数据
master：
保存save当前数据同步的位置
总体：
它们之间完成了数据克隆
089-主从复制-数据同步阶段注意事项
数据同步阶段 master说明
1.如果 master数据量巨大，数据同步阶段应避开流量高峰期，避兔造成 master阻塞，影响业务正常执行
2.复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存
在丢失的情况，必须进行第二次全量复制，致使s1ave陷入死循环状态
repl-backlog-size 1mb
3. master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行 bgsave命令和创建复制缓冲区
数据同步阶段slave说明
1.为避免s1ave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
slave-serve-stale-data yes|no
2.数据同步阶段， master发送给 slave信息可以理解 master是s1ave的一个客户端，主动向s1ave发送命令
3.多个s1ave同时对 master请求数据同步， master发送的RDB文件增多，会对带宽造成巨大冲击，
如果master带宽不足，因此数据同步霱要根据业务务需求，适量错峰
4.s1ave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是s1ave。
注意使用树状结构时，由于层级深度，导致深度越高的s1ave与最顶层 master间数据同步延迟较大，数据一致性变差，应谨慎选择090-主从复制-运行id(runid)
主从复制工作流程
阶段三：命令传播阶段
当 master数据库状态被修改后，导致主从服器数椐库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作称为'命令传播'
master将接收到的数据变更命令发送给slave,slave接收命令后执行命令
命令传播阶段的部分复制
命令传播阶段出现了断网现象
网络闪断闪连 忽略
短时间网络中断 部分复制
长时间网络中断 全量复制
部分复制的三个核心要素
服务器的'运行id(run id)'
主服务器的'复制积压缓冲区'
主从服务器的'复制偏移量'服务器运行ID(run id)
概念：
服务器运行ID是每台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
组成：
运行id由40位字符组成，是一个随机的十六进制字符
例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
作用：
运行id被用于在服务器间进行传输，识别身份
如果想两次操作均对同一台服务器进行，必须毎次操作携带对应的运行id，用于对方识别
实现方式：
运行id在每台服务器启动时自动生成的，
master在首次连接s1ave时，会将自己的运行ID发送给s1ave,
slave保存此ID，通过 info server命令，可以查看节点的run id091-主从复制-复制缓冲区与偏移量
复制缓冲区
概念：
复制缓冲区，又名复制积压缓中区，是一个先进先出（FFO）的队列，用于存储服务器执行过的命令，
每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
复制缓冲区内部工作原理
组成：
偏移量
字节值
工作原理：
通过offset区分不同的slave当前数据传播的差异
master记录已发送的信息对应的offset
slave记录已接受的信息对应的offset
复制缓冲区
概念：
复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，
每次传播命令， master都会将传播的命令记录下来，并存储在复制缓冲区
复制缓冲区默认数据存储空间大小是1M，由于存储空问大小是固定的，
当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
由来：
每台服务器启动时，如果开启有AOF或被连接成为 master节点，即创建复制缓冲区
作用：
用于保存 master收到的所有指令（仅指那些 会影响数据变更的指令，例set, select）
数据来源：
当 master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中主从服务器复制偏移量（ offset）
概念：
一个数字，描述复制缓中区中的指令字节位置
分类：
master复制偏移量：记录发送给所有s1ave的指令字节对应的位置（多个）
slave 复制偏移量：记录s1ave接收 master发送过来的指令字节对应的位置（个）
数据来源：
maste发送一次记录一次
作用：
同步信息，比对 master与s1ave的差异，当s1ave断线后，恢复数据使用092-主从复制-工作流程（2）数据同步与命令传播阶段（全）
093-主从复制-心跳机制与命令传播阶段工作流程
心跳机制：进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
master心跳：//master的心跳，只是为了判断slave是否还连接着
指令：ping
周期：由repl-ping-slave-period决定，默认10秒
作用：判断slave是否在线
查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
slave心跳任务：//slave的心跳 1为了获取数据 2判断master是否还连接着自己
指令：REPLCONF ACK{offset}
周期：1秒
作用1：汇报save自己的复制偏移量，获取最新的数据变更指令
作用2：判断 master是否在线心跳阶段注意事项
当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作
min-slaves-to-write 2
min-slaves-max-lag 8
slave数量少于2个，或者所有 slave的延迟都大于等于10秒时，强制关闭master向slave的写功能，停止数据同步
slave数量由：slave发送REPLCONF ACK命令做确认
slave延迟由：slave发送 REPLCONF ACK命令做确认
3.1.3 主从复制常见问题
094-主从复制-常见问题（1）
频繁的全量复制（1）
伴随着系统的运行， master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部s1ave的全量复制操作
内部优化调整方案：
1. master内部创建master_rep1id变量，使用runid相同的策略生成，长度41位，并发送给所有slave
2.在master关闭时执行命令 shutdown save，进行RDB持久化，将runid与 offset保存到RDB文件中
repl-id
repl -offset
通过 redis-check-rdb命令可以查看该信息
2. master重启后加载RDB文件，恢复数据
重启后，将RDB文件中保存的rep1-id与rep1-offset加载到内存中
master_repl_id = repl-id
master_repl_offset = repl-offset
通过info命令可以查看该信息
作用:
本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master频繁的全量复制（2）
问题现象
网络环境不佳，出现网络中断，s1ave不提供服务
问题原因
复制缓冲区过小，断网后s1ave的offset越界，触发全量复制
最终结果
slave反复进行全量复制（导致无法对外提供服务，看起来好像是slave不干活了，实际上它是在忙着进行全量复制）
解决方案
修改复制缓冲区大小
repl-backlog-size
建议设置如下
1.测算从master到s1ave的重连平均时长 second
2.获 master平均每秒产生写命令数据总量 write_size_per_second
3.最优复制缓冲区空间 = 2 * second * write_size_per_second095-主从复制-常见问题（2）
频繁的网络中断（1）
问题现象
master的CPU占用过高或s1ave频繁断开连接
问题原因
s1ave每1秒发送REPLCONF ACK命令到master
当s1ave接到了慢查询时(keys*， geta1l等)，会大量占用CPU性能
master每1秒调用复制定时函数 replicationCron()，比对s1ave发现长时间没有进行响应
最终结果
master各种资源（输出缓冲区、带宽、连接等）被严重占用
解决方案
通过设置合理的超时时间，确认是否释放slave
rep1-timeout
该参数定义了超时时间的阈值（默认60秒），超过该值，释放s1ave频繁的网络中断（2）
问题现象
s1ave与 master连接断开
问题原因
master发送ping指令频度较低
master设定超时时间较短
ping指令在网络中存在丢包
解决方案
提高ping指令发送的频度
repl-ping-slave-period
超时时间rep1-time的时间至少是ping指令频度的5到10倍，否则s1ave很容易判定超时096-主从复制-常见问题（3）
数据不一致
问题现象
多个s1ave获取相同数据不同步
问题原因
网络信息不同步，数据发送有延迟
解决方案
优化主从间的网络环境，通常放置在同一个机房部署，如使用可里云等云服努器时要注意此现象
监控主从节点延迟(通过 offset)判断，如果 slave延迟过大，暂时屏蔽程序对该slave的数据访问
slave-serve-stale-data yes|no //这个选项开启以后，专门供调试使用，不对外提供服务
开启后仅响应 info、 slaveof等少数命令（慎用，除非对数据一致性要求很高）主从复制：总结
主从复制
什么是主从复制
主从复制工作流程
三个阶段：
连接阶段、数据同步阶段、命令传播阶段
复制分全量复制和部分复制
三个核心：
部分复制分三个核心：runid、 复制积压缓存区、复制偏移量
心跳机制
维护着日常的数据传输
常见问题3.2 哨兵模式
3.2.1 哨兵简介
097-哨兵-哨兵简介
将宕机的 master下线
找一个slave作为 master
通知所有的save连接新的 master
启动新的 master-与save
全量复制*N+部分复制*N(配置的不好的话)谁来确认 master宕机了
找—个主？怎么找法？
修改配置后，原始的主恢复了怎么办？
哨兵简介
哨兵
哨兵(sentinel)是—个分布式系统，用于对主从结构中的每台服务器进行'监控'，
当岀现故障时通过投票机制'选择'新的master并将所有slave连接到新的master。
监控：监控它们干活
选择：出问题谁来做master哨兵的作用
监控
不断的检查master和slave是否正常运行。
master存活检测、 master与save运行情兄检测
通知（提醒）
当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
自动故障转移
断开master与slave连接，选取一个slave作为master，将其他slave连接到新的 master，并告知客户端新的服务器地址注意：
哨兵也是一台redis服务器，只是不提供数据服务
通常哨兵配置数量为单数(1 3 5 7 9 ...)3.2.2 启用哨兵模式
098-哨兵-哨兵结构搭建
启用哨兵模式
配置哨兵
配置一拖二的主从结构
配置三个哨兵（配置相同，端囗不同）
参看 sentinel. conf
启动哨兵
redis- sentinel1 sentinel1-端口号.conf复制文件，同时把文件中的26379改成26380
sed 's/26379/26380/g' ../sentinel-26379.conf > ../sentinel-26380.conf启动顺序：
先启主机，再启从机，最后启哨兵
redis-server /usr/local/redis-5.0.6/conf/redis-6379.conf
redis-server /usr/local/redis-5.0.6/conf/redis-6380.conf
redis-server /usr/local/redis-5.0.6/conf/redis-6381.conf
redis-sentinel /usr/local/redis-5.0.6/conf/sentinel-26379.conf//启动哨兵1
redis-cli -p 26379//启动哨兵1的client##########################哨兵的配置文件 sentinel-26379.conf##########################
# 哨兵本身也是一个服务，它对外也有一个服务端口，通常是2+6379
port 26380
# 把哨兵设置为守护进程方式启动，在此不使用它，我们需要看日志文件
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
# 哨兵的信息存储在哪里
dir /usr/local/redis-5.0.6/conf/logData
# mymaster(自定义的名称) ：检测的master，本处为 127.0.0.1 6379
# 2 ：2个哨兵认定master挂了，那么master就挂了；通常设定为哨兵数量的一半加一
sentinel monitor mymaster 127.0.0.1 6379 2
# 主机master多长时间没响应，认定它挂了，此处是30s(30秒认定主机下线)
sentinel down-after-milliseconds mymaster 30000
# 新的master上任以后，在进行数据同步以后，一次有多少个开始同步(越小，对服务器性能压力越小)
# 压力越小速度越慢，压力越大 速度越快
# 说白了就是，有几条线开始用时进行数据同步
sentinel parallel-syncs mymaster 1
# 多长时间内同步完成算有效，即超过这个时间同步没完成算超时(3分钟认定同步超时)
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes- 一个master，两个slave
三个哨兵 - 使用Ctrl+C停掉master
然后图片中的哨兵，选举6381为master
3.2.3 哨兵工作原理
099-哨兵-工作原理（1）
哨兵工作原理：主从切换
哨兵在进行主从切换过程中经历三个阶段
1.监控
2.通知
3.故障转移阶段一：监控阶段
用于同步各个节点的状态信息
获取各个 sentinel的状态（是否在线）
获取 master的状态
master属性
runid
role:master
各个save的详细信息
获取所有slave的状态（根据 master中的 Slave信息）
slave属性
runid
role:slave
master_host, master_port
offset
...
sentine
会向master、slave、其他sentinel要信息，
通过info要信息，
并与master和slave建立CMD通道(每一个sentinel都会和任意一个master和slave建立CMD通道)，便于以后的信息流动
sentinel之间直接会建立一个publish和subscribe通道，进行信息同步100-哨兵-工作原理（2）
哨兵工作原理
阶段二：通知阶段(信息的长期维护阶段)(维护一个长期的信息对等)
101-哨兵-工作原理（3）
上图
一个sentinel向master和slave发送hello指令，收到正常回复，确认它们都正常工作
然后就会在sentinel的局域网内部，告诉大家它们都正常工作
上图：
当一个sentinel发现master挂了时，就不停的向master发送hello，但是master没反应
上图
这个时候，这个sentinel就认为 这个master挂掉了，
会把flags置为SRI_S_DOWN 即主观下线
同时向局域网内的其他sentinel说，这个master下线了
上图
这个时候，其他的sentinel就会去确认，这个master是否真的下线了
(各自向master发送hello，并等待回复)
上图
这时候sentinel们，根据返回来的信息，进行投票，最终投票决定master是否下线
上图
投票的数目 > sentinel的一半时，就都认为master下线了
会把flags置为SRI_O_DOWN 即客观下线
一旦进入到客观下线阶段，开始进入下一环节：清理队伍主观下线：一台sentinel认为master挂了
客观下线：超过半数以上的sentinel认为master挂了下图
sentinel中选一个头目，去执行清理队伍的任务
它们会去竞选谁去当这个头目：通过投票机制
谁先到达，它就会把票投给谁
参与竞选的sentinel会发送的信息包括：
挂的ip和port
自己参与竞选的次数
自己的runid
如果没有决出胜负：再来一轮，同时竞选次数加一
sentinel选出了头目以后，
这个头目就根据自己的四大原则，
从备选服务器中，筛选出一个master
上图：原则1 - 在线的
上图：原则2 - 响应慢的
上图：原则3 - 与原master断开时间久的//即 与原master离得最近的
阶段三：故障转移阶段
服务器列表中挑选备选master
1.在线的
2.响应慢的
3.与原master断开时间久的//即 与原master离得最近的
4.优先原则
优先级
offset
runid
发送指令（sentinel）
向新的master发送slaveof no one //让新的master与上一个master打开从属关系
向其他slave发送slaveof新masterIP端口 //让其他的slave都连接、隶属于这个新的master的IP和Port总结
哨兵工作原理
阶段三：故障转移阶段
·监控
同步信息//识别对方
·通知
保持联通//保持信息对称
·故障转移
发现问题
竞选负责人
优选新master
新master上任，其他slave切换master，原master作为slave故障回复后连接
下图
现在重新启动原来的master
在哨兵sentinel的界面，可以看到，它转换为slave，slaveof于这个新的master
3.3 集群
3.3.1 集群简介
102-集群-集群简介
现状问题
业务发展过程中遇到的峰值瓶颈
redis提供的服务OPS可以达到10万/秒，当前业务OPS已经达到20万/秒
内存单机容量达到256G，当前业务需求内存容量1T
使用集群的方式可以快速解决上述问题
一主一从
多主多从
集群架构
集群就是使用网络将若干台计算机连通起来，并提供统一的管理方式，使其对外呈现单机的服务效果
集群作用
分散单台服务器的访问压力，实现负载均衡
分散单台服务器的存储压力，实现可扩展性
降低单台服务器宕机带来的业务灾难
3.3.2 Redis集群结构设计
103-集群-集群存储结构设计
1.数据存储设计
集群存储结构设计
1.数据存储设计
2.集群内部通讯设计
上图
数据通过算法计算，计算出保存的位置
每一份存储空间，称为一个槽
上图
增强可扩展性
增加了新的存储空间(存储节点)时
就会从原来的每个存储空间里面分出来一部分，存到新增加的这个存储空间
所谓的增节点和去节点，就是改变这些槽的存储位置
一个机器持有一定的槽，
当加机器的时候，把它的槽分一部分给新的机器
去机器的话，把它的槽，给其他的机器(存储节点)2.集群内部通讯设计
三个存储机器
它们之间互联
谁存储着什么东西，大家心里都一清二楚
也就是说，它们心里都有一个账本，记录着各个计算机里面存储的槽(存储空间)
总结
槽用来区分数据内部的存储空间
key通过算法运算以后，确定它存储的位置
查找数据时，要么一次命中 要么两次命中，提高访问性能3.3.3 cluster集群结构搭建
104-集群-cluster集群搭建
cluster集群结构搭建
cluster的conf配置
·设置加入cluster，成为其中的节点
cluster-enabled yeslno
·cluster配置文件名，该文件属于自动生成，仅用于快速查找文件并查询文件内容
cluster-config-file <filename>
·节点服务响应超时时间，用于判定该节点是否下线或切换为从节点
cluster-node-timeout <milliseconds>
·master连接的slave最小数量
cluster-migration-barrier <count>##########################哨兵的配置文件 sentinel-26379.conf##########################
# 哨兵本身也是一个服务，它对外也有一个服务端口，通常是2+6379
port 26380
# 把哨兵设置为守护进程方式启动，在此不使用它，我们需要看日志文件
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
# 哨兵的信息存储在哪里
dir /usr/local/redis-5.0.6/conf/logData
# mymaster(自定义的名称) ：检测的master，本处为 127.0.0.1 6379
# 2 ：2个哨兵认定master挂了，那么master就挂了；通常设定为哨兵数量的一半加一
sentinel monitor mymaster 127.0.0.1 6379 2
# 主机master多长时间没响应，认定它挂了，此处是30s(30秒认定主机下线)
sentinel down-after-milliseconds mymaster 30000
# 新的master上任以后，在进行数据同步以后，一次有多少个开始同步(越小，对服务器性能压力越小)
# 压力越小速度越慢，压力越大 速度越快
# 说白了就是，有几条线开始用时进行数据同步
sentinel parallel-syncs mymaster 1
# 多长时间内同步完成算有效，即超过这个时间同步没完成算超时(3分钟认定同步超时)
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
################# 开启cluster集群
# 开启cluster，这样才能成为集群中的节点
cluster-enabled yes
# 配置文件的名字
cluster-config-file nodes-6379.conf
# 这个节点下线的时间，（此处演示，设为10s）
cluster-node-timeout 10000sed "s/6379/6380/g" redis-cluster-6379.conf > redis-cluster-6380.conf
...
sed "s/6379/6384/g" redis-cluster-6379.conf > redis-cluster-6384.conf开一个三主三从的集群结构
master1 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6379.conf
master2 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6380.conf
master3 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6381.conf
slave4 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6382.conf
slave5 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6383.conf
slave6 -- redis-server /usr/local/redis-5.0.6/conf/redis-cluster-6384.conf
主命令操作客户端--大量命令都在这个client中进行操作
master1-client
slave1-client
机动客户端--需要看其他master和slave客户端时，就用这个机动客户端去看
上图
查看各个服务器是否都启动了
下面，我们来把这些节点连接在一起
需要用到redis/src目录下的一个redis命令：redis-trib.rb
使用redis-trib.rb，需要安装：ruby、gem
yum install ruby
yum install gem
[root@lwh src]# ruby -v
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
[root@lwh src]# gem -v
2.0.14.1
[root@lwh src]#使用redis-trib.rb创建集群
cd /usr/local/redis-5.0.6/src/
./redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384
# create:创建集群
# --replicas 1 : 指定内部结构，1代表一个master连接一个slave ，2 代表一个master连接两个slave ...
# 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384: 前面三个是master，后面三个是slave，它们会依次连接# 执行：
./redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383
# 发现并没有执行成功，这是因为：
# 5.0之后 trib.rb 全部移植到了 redis-cli --cluster， 下面 ruby 和 gem 也不用下载
# 根据提示：指令变为
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1
# 运行这行指令，发现master6379出错，利用fix指令进行修复
#[ERR] Not all 16384 slots are covered by nodes.
redis-cli --cluster fix 127.0.0.1:6379
# 利用check指令，检查是否已经完全修复，可以看出，16384个槽都已经正常
redis-cli --cluster check 127.0.0.1:6379
...
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.正常的启动界面如下
105-集群-设置与获取数据
集群中：
数据的设置和获取
上图的操作方式，太麻烦了；使用下图的方式操作即可解决
106-集群-主从下线与主从切换
正常的操作，不是cluster最大的优势，它最大的优势是 出问题之后怎么办cluster节点(手动)操作命令
·查看集群节点信息
cluster nodes
·进入一个从节点redis，切换其主节点
cluster replicate <master-id>
·发现一个新节点，新增主节点
cluster meet ip:port
·忽略一个没有solt的节点
cluster forget <id>
·手动故障转移
cluster failover
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
