单机缺点及解决方案
单机问题：机器故障数据丢失、容量瓶颈。QPS瓶颈
需要集群的原因：
- 并发量OPS的需求。要超过10w/s。
- 数据量“大数据”，机器只能存256G，但是需要存500G
3．集群可以备份数据
Redis不能支撑高并发的瓶颈--单机
单机的redis几乎不太可能说QPS(并发)超过10万+，除非特殊情况，如机器性能特别好，配置特别高，物理机，维护做的特别好，而且整体的操作不是太复杂
Redis三种策略：
- 主从复制 ：
- 哨兵:哨兵机制为了解决主从复制的缺点的
- 集群:
选型：
单机：如果数据量很少，主要是承载高并发高性能的场景，如缓存一般就几个G，单机足够
主从Replication：一个mater，多个slave，要几个slave跟要求的读吞吐量有关系，然后搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了
集群redis cluster：主要是针对海量数据+高并发+高可用的场景，海量数据，如果数据量很大，建议用redis cluster
主从复制(Redis master slave replication)
主从复制：一主多从，主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
容易水平扩展，只需要增加redis slave就可以了
对主进行了数据备份。对主进行了分流，读操作转移到slave中（读写分离和容灾恢复）
redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构
数据同步：
Redis在master是非阻塞模式，即在slave执行数据同步时，master可接受客户端请求，并不影响同步数据一致性，
在slave端是阻塞模式的，slave在同步master数据时，并不能够响应客户端的查询
Redis的master/slave模式下，master提供数据读写服务，而slave只提供读服务
特点：
1.master可配置多个slave；一个slave只能有一个master，slave可连接其他slave形成图状结构。数据流向是单向的，从master到salve
2. redis采用异步方式复制数据到slave节点，redis 2.8开始，slave node会周期性地确认自己每次复制的数据量。
Master：复制时不会阻塞。当一或多个slave与master进行初次同步数据时，master可继续处理client发来的请求；
Slave：在初次同步数据时则会阻塞不能处理client的请求. 在做复制时，不会阻塞对自己的查询操作，会用旧的数据集来提供服务; 但是复制完成时需删除旧数据集，加载新数据集，这时就会暂停对外服务
3. 主从复制可用来提高系统的可伸缩性,可以用多个slave 专门用于client的读请求，（数据副本、扩展读性能（读写分离））
如sort操作可用slave来处理。也可用来做简单的数据冗余
4．slave node主要用来进行横向扩容，做读写分离，扩容slave node可提高读的吞吐量
过程：
1、当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。
2无论第一次同步建立连接还是连接断开后重新连接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。
3后台进程完成写文件后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。
4接着master就会把缓存的命令转发给slave。后续master收到的写命令都会通过开始建立的连接发送给slave。
注：
从master到slave的同步数据的命令和从 client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave。(通过网络传输的方式发个slave)
当启动一个slave node的时候，它会发送一个PSYNC命令给master node
如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据;
否则如果是slave node第一次连接master node，那么会触发一次full resynchronization
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令异步发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
复制的完整流程
（1）slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始
master host和ip是从redis.conf里面的slaveof配置的
（2）slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
（3）slave node发送ping命令给master node
（4）口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
（5）master node第一次执行全量复制，将所有数据发给slave node
（6）master node后续持续将写命令，异步复制给slave node
数据同步相关的核心机制
指第一次slave连接msater的时候，执行的全量复制，那个过程里面一些细节的机制
（1）master和slave都会维护一个offset
master会在自身不断累加offset，slave也会在自身不断累加offset
slave每秒都会上报自己的offset给master，同时master会保存每个slave的offset
这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况
（2）backlog
master node有一个backlog，默认1MB大小
master node给slave node复制数据时，也会将数据在backlog中同步写一份
backlog主要是用来做全量复制中断候的增量复制的
（3）master run id
info server，可以看到master run id
如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制
如果需要不更改run id重启redis，可以使用redis-cli debug reload命令
连接时会创建一个标识，当run_id发生变化时，意味着需要同步
（4）psync
从节点使用psync从master node进行复制，psync runid offset
master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制
无磁盘化复制
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了
repl-diskless-sync
repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来
过期key处理
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave
断点续传：
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制
但是如果没有找到对应的offset，那么就会执行一次resynchronization
缺点：
主节点宕机后，就不可写了。系统崩溃。可以使用哨兵机制选举出新的master
实现主从复制的两种方式：
1.通过slaveof命令
主从复制：
取消复制：
2.配置文件配置主从
修改配置的方式：
slaveof ip port
slave-read-only yes
1)主节点配置：
daemoize yes
pidfile /var/run/redis-6379.pid
logfile “6379.log”
#save 900 1
#save 300 10
#save 60 10000
dbfilename dump-6379.rdb
dir /opt/redis/data
2)从节点配置：
slaveof 192.168.1.1 6379 #指定master的ip和端口
客户端查看信息：info replication
复制过程：
3.两种方式的比较
| 方式 |
命令 |
配置 |
| 优点 |
无需重启 |
统一配置 |
| 缺点 |
不便于管理 |
需要重启 |
master持久化对主从架构的安全保障的意义
可在master禁用数据持久化，只需注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。（只在slave中做持久化，但这样做容易丢数据）
如果采用主从架构，建议必须开启master node的持久化！
不建议用slave node作为master node的数据热备，因为如果关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了
master -> RDB和AOF都关闭了 -> 全部在内存中
master宕机，重启，没有本地数据可恢复，会直接认为自己数据是空的。master就会将空的数据集同步到slave上去，所有slave的数据全部清空。100%的数据丢失
总结：master节点，必须要使用持久化机制
第二个，master的各种备份方案，要不要做，万一本地所有文件丢失；从备份中挑选一份rdb去恢复master; 这样才能确保master启动的时候，是有数据的
即使采用了后续讲解的高可用机制，slave node可自动接管master node，但是也可能sentinal还没有检测到master failure，master node就自动重启了，还是可能导致上面的所有slave node数据清空故障
全量复制
（1）master执行bgsave，在本地生成一份rdb快照文件
（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或一次性超过256MB，那么停止复制，复制失败
（6）slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间
如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟
全量复制的开销大：
11、bgsave时间
2、RDB网络
增量复制（部分复制）
（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog是1MB
（3）msater就是根据slave发送的psync中的offset来从backlog中获取数据的
heartbeat
主从节点互相都会发送heartbeat信息
master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
异步复制
master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node
开发与运维中的问题
1.读写分离：读流量分摊到从节点
可能遇到的问题：
复制数据延迟。数据一致性问题。
读到过期数据。
从节点故障
2.主从配置不一致：
1、
小的触发了淘汰机制
3.规避全量复制
4.规避复制风暴
哨兵机制（Sentinel）
哨兵机制是为了解决主从复制的缺点的：
主从复制高可能问题：
1、如果主节点出现问题，需手工解决问题，也就是重启master或手工选择一个slave，使用slaveof no one命令或slaveof new master命令选出主和从。需要单独写脚本处理。问题是如何判断节点故障，如何将命令发送给节点
2、写能力和存储能力受限，写只在一个节点
sentinal哨兵： redis集群架构中重要的组件，主要功能如下
（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址
哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及分布式选举的问题
（2）即使部分哨兵节点挂掉了，哨兵集群还能正常工作，如果只有一个哨兵，不合理。
目前采用sentinal 2版本，sentinal 2相对sentinal 1主要是让故障转移的机制和算法变得更加健壮和简单
主节点宕机后故障转移过程：
多个sentinel发现并确认master有问题
选举出一个sentinel作为领导
选举出一个slave作为master
通知其他slave成为新的master的slave
通知客户端主从变化
等待老的master复活成为新的master的slave
哨兵的核心知识
（1）哨兵至少需要3个实例，来保证自己的健壮性
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
仅2节点的redis哨兵集群无法正常工作：
哨兵集群必须部署2个以上节点
如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1
+----+ +----+
| M1 |---------| R1 |
| S1 | | S2 |
+----+ +----+
Configuration: quorum = 1
master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移
这时，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移
如果整个M1和S1运行的机器宕机了，哨兵只有1个，没有majority来允许执行故障转移，虽然还有一个R1，但故障转移不会执行。所以两个节点的哨兵无法正常工作
经典的3节点哨兵集群
+----+
| M1 |
| S1 |
+----+
|
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
Configuration: quorum = 2，majority
若M1所在机器宕机，3个哨兵还剩2个，S2和S3可一致认为master宕机，然后选出一个来执行故障转移
3个哨兵的majority是2，有2个哨兵运行着，就可以允许执行故障转移
哨兵主备切换的数据丢失问题及解决方案：
redis哨兵主备切换的数据丢失问题：异步复制、集群脑裂
1、两种数据丢失的情况
主备切换的过程，可能导致数据丢失
1）异步复制导致的数据丢失
因master -> slave的复制是异步的，所以可能master有部分数据在master内存中还没复制到slave，master就宕机了，此时这些部分数据丢失
2）集群脑裂导致的数据丢失
脑裂，即某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着
此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master
这时，集群里有两个master，也就是所谓的脑裂
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了
因此旧master再次恢复网络时，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
2、解决异步复制和脑裂导致的数据丢失
min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1个slave，数据复制和同步的延迟不能超过10秒
如果说一旦所有的slave，数据复制和同步的延迟都超过10秒钟，这时，master就不会再接收任何请求
上面两个配置可以减少异步复制和脑裂导致的数据丢失
1）减少异步复制的数据丢失
有了min-slaves-max-lag配置，可确保一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了。
这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
降低损失，就是损失10s的数据。禁止客户端向master写入。等待slave同步完成。客户端被拒绝后，将采用服务降级的方案，如kafka。保存数据。这一点需要客户端自己编写代码实现。
2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求
这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失
上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求
因此在脑裂场景下，最多就丢失10秒的数据
redis哨兵的多个核心底层原理的深入解析（包含slave选举算法）
1、sdown和odown转换机制
sdown和odown两种失败状态
sdown是主观宕机：一个哨兵如果自己觉得一个master宕机了
odown是客观宕机：quorum数量的哨兵都觉得一个master宕机了
sdown达成条件简单：如果一个哨兵ping一个master，超过is-master-down-after-milliseconds指定的毫秒数，就主观认为master宕机
sdown到odown转换的条件很简单：如果一个哨兵在指定时间内，收到quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机
2、哨兵集群自动发现机制
哨兵互相之间的发现，是通过redis的pub/sub系统实现的，
每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时所有其他哨兵都可消费到这个消息，并感知到其他哨兵的存在
每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置
每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
3、slave配置的自动纠正
哨兵会负责自动纠正slave的一些配置，
如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据;
如slave连接到一个错误的master上，如故障转移之后，哨兵会确保它们连接到正确的master上。
如一个哨兵让slave变成了master，哨兵会让其他slave修改配置，连接到新的master。
4、slave->master选举算法
如果一个master被认为odown，且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来
选举考虑。会考虑slave的一些信息：
（1）跟master断开连接的时长
如果一个slave跟master断开连接超过down-after-milliseconds的10倍，外加master宕机的时长，slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
（2）slave优先级：
（3）复制offset
（4）run id
判断断开时长后，对slave进行排序，然后根据以下顺序判断：
1）按slave优先级进行排序，slave priority越低，优先级越高（slave priority可以进行配置的）
2）如果slave priority相同，就看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
3）如果上面两个条件都相同，就选择一个run id比较小的那个slave
5、quorum和majority
每次一个哨兵要做主备切换，先要quorum数量的哨兵认为odown，然后选举一个哨兵来做切换，这个哨兵还要得到majority哨兵的授权，才能正式执行切换。
如果quorum < majority，如5个哨兵，majority是3，quorum设置为2，要3个哨兵授权才可执行切换
如果quorum >= majority，必须quorum数量的哨兵都授权，如5个哨兵，quorum是5，必须5个哨兵都同意授权，才能执行切换
quorum解释如下：
（1）至少多少个哨兵要一致同意，master进程挂掉，或slave进程挂掉了，或者要启动一个故障转移操作
（2）quorum是用来识别故障的，真正执行故障转移的时候，还要在哨兵集群执行选举，选举一个哨兵进程出来执行故障转移操作
（3）假设有5个哨兵，quorum设置了2，那么如果5个哨兵中的2个都认为master挂掉了; 2个哨兵中的一个就会做一个选举，选举一个哨兵出来，执行故障转移; 如果5个哨兵中有3个哨兵都是运行的，那么故障转移就会被允许执行
6、configuration epoch版本号
哨兵会对一套redis master+slave进行监控，有相应的监控的配置
执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch版本号，每次切换的version号都必须唯一
如果第一个选举出的哨兵切换失败，其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号
7、configuraiton传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，通过pub/sub消息机制
这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的
其他的哨兵都是根据版本号的大小来更新自己的master配置的
经典的3节点方式部署哨兵集群
练习如何操作部署哨兵集群，如何基于哨兵进行故障转移，还有一些企业级的配置方案
1、哨兵的配置文件（最小的配置）
sentinel.conf
每一个哨兵都可以去监控多个maser-slaves的主从架构。因为可能公司里，为不同的项目，部署了多个master-slaves的redis主从集群。相同的一套哨兵集群，就可以去监控不同的多个redis主从集群。给每个redis主从集群分配一个逻辑的名称
最小的哨兵配置，如果发生master-slave故障转移，或新的哨兵进程加入哨兵集群，那么哨兵会自动更新自己的配置文件
# 监控名字为mymaster
sentinel monitor mymaster 127.0.0.1 6379 2 # 最后一个值是quorum
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
# 监控名字为resque
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
上面这段配置，就监控了两个master node
配置分析：
sentinel monitor mymaster 127.0.0.1 6379 #指定对一个master的监控，给监控的master指定一个名称，可配置多个master做数据拆分
sentinel down-after-milliseconds mymaster 60000 #超多少毫秒跟一个redis实例断了连接，哨兵就可能认为这个redis实例挂了
sentinel failover-timeout mymaster 180000 # 执行故障转移的timeout超时时长
sentinel parallel-syncs mymaster 1 # 新的master别切换之后，同时有多少个slave被切换到去连接新master，重新做同步，数字越低，花费的时间越多
上面的三个配置，都是针对某个监控的master配置的，给其指定上面分配的名称即可
sentinel monitor master-group-name hostname port quorum
parallel-syncs的解释：
假设redis是1个master，4个slave
master宕机，4个slave中有1个切换成master，剩下3个slave就要挂到新的master上面去
这时，如果parallel-syncs是1，那么3个slave，一个一个地挂接到新的master上面去，1个挂接完，而且从新的master sync完数据之后，再挂接下一个。
如果parallel-syncs是3，那么一次性就会把所有slave挂接到新的master上去
2、在eshop-cache03上再部署一个redis
只要安装redis就可以了，不需要去部署redis实例的启动
wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd /usr/local/tcl8.6.1/unix/
./configure
make && make install
使用redis-3.2.8.tar.gz（截止2017年4月的最新稳定版）
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test
make install
2、正式的配置
哨兵默认用26379端口，默认不能跟其他机器在指定端口连通，只能在本地访问
mkdir /etc/sentinal
mkdir -p /var/sentinal/5000
/etc/sentinel/5000.conf
port 5000
bind 192.168.31.187
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.19
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.227
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
3、启动哨兵进程
在eshop-cache01、eshop-cache02、eshop-cache03三台机器上，分别启动三个哨兵进程，组成一个集群，观察一下日志的输出
redis-sentinel /etc/sentinal/5000.conf
redis-server /etc/sentinal/5000.conf --sentinel
日志里会显示出来，每个哨兵都能去监控到对应的redis master，并能够自动发现对应的slave
哨兵之间，互相会自动进行发现，用的就是pub/sub，消息发布和订阅channel消息系统和机制
4、检查哨兵状态
redis-cli -h 192.168.31.187 -p 5000
sentinel master mymaster
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
SENTINEL get-master-addr-by-name mymaster
对项目中的哨兵节点进行管理以及高可用redis集群的容灾演练
1、哨兵节点的增加和删除
增加sentinal，会自动发现
删除sentinal的步骤
（1）停止sentinal进程
（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
2、slave的永久下线
让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行
3、slave切换为Master的优先级
slave->master选举优先级：slave-priority，值越小优先级越高
4、基于哨兵集群架构下的安全认证
每个slave都有可能切换成master，所以每个实例都要配置两个指令
master上启用安全认证，requirepass
master连接口令，masterauth
sentinal，sentinel auth-pass <master-group-name> <pass>
5、容灾演练
通过哨兵看一下当前的master：SENTINEL get-master-addr-by-name mymaster
把master节点kill -9掉，pid文件也删除掉
查看sentinal的日志，是否出现+sdown字样，识别出了master的宕机问题; 然后出现+odown字样，就是指定的quorum哨兵数量，都认为master宕机了
（1）三个哨兵进程都认为master是sdown了
（2）超过quorum指定的哨兵进程都认为sdown之后，就变为odown
（3）哨兵1是被选举为要执行后续的主备切换的那个哨兵
（4）哨兵1去新的master（slave）获取了一个新的config version
（5）尝试执行failover
（6）投票选举出一个slave区切换成master，每隔哨兵都会执行一次投票
（7）让salve，slaveof noone，不让它去做任何节点的slave了; 把slave提拔成master; 旧的master认为不再是master了
（8）哨兵就自动认为之前的187:6379变成了slave了，19:6379变成了master了
（9）哨兵去探查了一下187:6379这个salve的状态，认为它sdown了
所有哨兵选举出了一个，来执行主备切换操作
如果哨兵的majority都存活着，那么就会执行主备切换操作
再通过哨兵看一下master：SENTINEL get-master-addr-by-name mymaster
尝试连接一下新的master
故障恢复，再将旧的master重新启动，查看是否被哨兵自动切换成slave节点
（1）手动杀掉master
（2）哨兵能否执行主备切换，将slave切换为master
（3）哨兵完成主备切换后，新的master能否使用
（4）故障恢复，将旧的master重新启动
（5）哨兵能否自动将旧的master变为slave，挂接到新的master上面去，而且也是可以使用的
6、哨兵的生产环境部署
daemonize yes
logfile /var/log/sentinal/5000
mkdir -p /var/log/sentinal/5000
哨兵机制虽然可以做到高可用，但是无法做到分布式，数据都存在一个master中。
而分布式，就需要集群。集群还支持扩容。