注：本篇记录一下，学过Redis教程后记录下来的操作命令
目录
简介
Redis是一个高速缓存的NoSql数据库。可支持持久化。就是把数据写到硬盘。基于key-value来进行缓存。
首先引用一下百度百科中的介绍。
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的(单命令)。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
数据类型&命令
1、字符串
应用场景：今天我们有多少个独立用户访问（字符串） 微博数、粉丝数。
setbit cc 1 1 //设置 cc key的 1号位 是1
setbit cc 2 1
getbit cc 2 >1 //获取 cc key的 1号位的值
getbit cc 3 >
bitcount cc >2 //获取有多少个位
incr incrby decr decrby
getrange z 0 4 //获取索引段的值
setrange z 0 asd //覆盖索引0开始往后覆盖，直到把值asd写入
getset z asd //设置值为新值并返回旧值。
strlen z //返回字符串长度。
setex c 10 d //设置 c 的值为 d 有效期为 10s 这个是原子的。 ttl查看时间
psetex c 4000 d //设置 c 的值为 d 有效期为 4000ms 这个是原子的。 pttl查看时间
setnx c d //设置c 的值为d 如果不存在的话。 存在就不设置了。
mset mget //多个批量操作。
2、list
被用作消息队列， 关注列表 粉丝列表
微博热点缓存。 缓存5000条热搜ID。 可以做队列，使用lrange 分页。
list理解成一个栈。或者理解成 ----> 这样的一个队列、l就是左边进 r就是右边进 lpush 就是从栈底入栈 rpush 就是从栈顶入栈。
lrange asdkey 0 -1 (start end) //-1表示到最后。list 查里面的是啥
lpop rpop //就是删最边上的元素。
BRPOP它是 RPOP 命令的阻塞版本，当给定列表内没有任何元素可供弹出的时候，连接将被 BRPOP 命令阻塞,直到等待超时或发现可弹出元素为止。B 开头的就是阻塞的。
lpush z 1 2 3
lpushx z 1 //跟lpush区别就是如果key不存在那么什么也不做。
llen z //看z的长度、
lrem [key] [count] [value] //可以理解为,从index为0的位置开始遍历这个list,删除值为value的项,直到删除count项为止
lrem z 2 as //从 左边/栈底 删 l开头、
lindex z 0 //取索引下标的元素 <l开头> 不会弹出，只是get
lset z 1 9 //将列表的 索引(1) 位改值为9
ltrim z 0 4 将key截取 索引段 其余数据丢掉。 闭区间。
LINSERT key BEFORE|AFTER pivot value
linsert z after 4 99 //将值 value 插入到列表 key 当中，位于值 pivot 之前或之后。当 pivot 不存在于列表 key 时，不执行任何操作。
3、hash
存储对象信息 id =>{name,hobby} 将多个分散的字符串类型key转成hash能节约内存。单点登录存用户信息
hkeys hashkey //获取hashkey中的所有filed
hgetall hashkey //获取hashkey中所有的filed和value 会替换交叉展示、
hget key field //获取指定hashkey 指定field的value值
hvals key //获取key的所有值。
hkeys key //获取所有 field。
hmset aa a 5 b 6 //操作多个field
hmget aa a b
hdel aa a b //删除多个field
hsetnx key field value //将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在。field存在就改不了了。
hexists z s //看key中field 是否存在。
hincrby k f 5 //将对应field的值+5 可以为负的就是减 只能是整数。
hincrbyfloat z a -1.1 //操作浮点数。
hlen z //看field个数。
4、set 集合
hashtable实现，crud都是O(1) 去重。
微博：所有粉丝作为一个key 的元素，还可以求共同好友啥的。 交并差集 共同好友，我喜欢啥的。
有时候需要对值的属性进行标记和跟踪处理，但不能通过简单的复制操作完成，集合数据结构是解决此类问题的最好方法之一。当然，对于那些需要运用集合操作的地方（例如交集和并集），集合数据结构就是最好的选择。
sadd a 1 2 3 4 2 //集合是唯一的，当加入存在的元素(2)会加不进去的。
sadd b 3 4 5 6
sdiff a b //返回 1 2 去掉a b中共有的剩余a的集合。
sdiffstore c a b //将diff结果存入c
sinter a b //返回 3 4 返回交集。
sinterstore c a b //同上 存储交集到c
sunion a b //求并集
sunionstore c a b //将并集结果存入c
scard a //返回 key里面有多少个元素。
smembers //返回集合里面的所有元素。
srandmember a 2 //随机返回2两个元素。
spop a //随机删除一个元素并返回。
sismember a 3 //判断3是不是a里面的元素。
smove a b 1 //原子性的将a中的1 元素移到b里面。
srem b 5 6 //移除多个元素
5、sorted set分类集合(zset)
以得分的形式加入分类集合元素， 去重有序，根据score排序，带权重的操作、 重复添加的元素会更新score值。
排行榜 TOP n
zadd d 10 "a" 20 "b" //添加值并赋予得分
zrange d 0 -1 [withscores] //返回分类集合的元素，可加得分情况
zcard d //返回分类集合中的元素数量
zcount d 20 30 //返回score在 [20,30]里面的元素。
zrangebyscore d (10 20 //根据得分区间返回元素。 前面加( 表示开区间，默认闭区间。
zscore d c //获取 c的score
zincrby d 10 tom //将tom增加10分
zrank d c //查看key(d)中c按得分的排名 0是第一名
zrem d a //删除a 删除多个元素
zremrangebyrank d 0 1 //删除排名段内的数据。
zremrangebyscore d 10 200 //删除指定得分区间的数据。
6、key 等base操作
del key //删除key
exists key //判断key是否存在。
keys asd* //查看key
type asdkey //查某个key的数据类型
dump key //序列化某个key
restore b 0 "\x00\aqwerasd\t\x00\xbe\x06\xe9M#\xa8\xd0j" //将值以0(永久) ttl 反序列化到一个key b
expire b 10 //设置过期时间为 10s
expireat b 1590721735 //设置过期时间为一个时间戳的时间。
pexpire b 1000 //以毫秒设置过期时间
persist b //删除key的过期时间。
move key db //将key移到别的库。
migrate host port key destination-db timeout [COPY] [REPLACE]
将 key 原子性地从当前实例传送到目标实例的指定数据库上，一旦传送成功， key 保证会出现在目标实例上，而当前实例上的 key 会被删除。
rename k1 k2 //将k1改名为k2 k1不存在返回错误。 删除k1 并将k1的值覆盖掉k2的值 不同数据类型也可以，但是只是替换key的名字 内容不变。相同数据类型会完全覆盖。
renamenx k1 k2 //当k2不存在时 重命名。
randomkey //当前数据库随机返回一个key
lpush z 3 1 54 5 1 5 3 2
sort z desc //排序一个key
lpush a 'ads' 'dd' 'abc' 'daqdw'
sort a alpha desc //排序字符串需要加 alpha desc 表示正序还是倒序。
sort a alpha desc limit 1 2 //可以加limit 跟sql的用法一样。
sort 还可以根据外部key进行排序 用外部key作为变量排序。 感觉想不到应用场景。
config get *log* //查看redis.conf配置
事务
Redis是单线程，原子性的。 但是多条Redis命令需要被事务包裹才能顺序执行。(单线程，但是多客户端)
multi 开启一个事务。
incr a 事务要执行的命令 执行回复 queued
exec 执行命令
discard 客户端清空事务队列，并放弃执行事务。
如果exec执行之前出现问题，那么这个事务一定是执行失败的。
即使事务中有某条/某些命令执行失败了， 事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令。
事务不支持回滚。
redis中使用了 watch来保证不会出现不可重复读、
WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。 实现了乐观锁。
WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效， 直到调用 EXEC 为止。
unwatch取消监控。
watch key需要执行在multi事务开启之前，对指定key进行监控。
如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 key 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。程序是你自己写的！不是redis自个重试。
redis可以使用lua脚本达成事务的效果。
发布与订阅
SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三个命令实现了发布与订阅信息泛型
发送者将消息发送到通道，接收者只需从感兴趣的通道取就行了，发送者和接收者之间是解耦的。
SUBSCRIBE 、 UNSUBSCRIBE 是客户端订阅频道和取消订阅的命令
SUBSCRIBE foo bar 订阅两个频道。
正在订阅的客户端不能发送除了SUBSCRIBE 、 UNSUBSCRIBE 之外的命令。当客户端订阅的频道数量为0时就可以执行Redis正常命令了。
起两个客户端：
127.0.0.1:6379> subscribe cc ----------1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "cc"
3) (integer) 1 >>>当前Redis客户端监听了多少个channel
1) "message"
2) "cc"
3) "hello-zhangyong"
127.0.0.1:6379> publish cc hello-zhangyong ----------2
(integer) 1
还可以监听一个模式
127.0.0.1:6379> psubscribe cc.* -----cc. 为前缀的
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "cc.*"
3) (integer) 1
1) "pmessage"
2) "cc.*"
3) "cc.a"
4) "1"
1) "pmessage"
2) "cc.*"
3) "cc.b"
4) "2"
127.0.0.1:6379> publish cc.a 1
(integer) 1 ------接收到的客户端数量
127.0.0.1:6379> publish cc.b 2
(integer) 1
主从复制
主服务器可以有多个从服务器，从服务器也可以有从服务器，可以让多个从服务器处理读命令来提升扩展性。
可以通过复制功能，来让主服务器免于执行持久化操作，关闭主服务器的持久话功能，让从服务器去做持久话操作。
无论是初次连接还是重新连接， 当建立一个从服务器时， 从服务器都将向主服务器发送一个 SYNC 命令。
接到 SYNC 命令的主服务器将开始执行 BGSAVE ， 并在保存操作执行期间， 将所有新执行的写入命令都保存到一个缓冲区里面。
当 BGSAVE 执行完毕后， 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器， 从服务器接收这个 .rdb 文件， 并将文件中的数据载入到内存中。
之后主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。
psync
这个特性需要主服务器为被发送的复制流创建一个内存缓冲区（in-memory backlog）， 并且主服务器和所有从服务器之间都记录一个复制偏移量（replication offset）和一个主服务器 ID （master run id）， 当出现网络连接断开时， 从服务器会重新连接， 并且向主服务器请求继续执行原来的复制进程：
如果从服务器记录的主服务器 ID 和当前要连接的主服务器的 ID 相同， 并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面， 那么主服务器会向从服务器发送断线时缺失的那部分数据， 然后复制工作可以继续执行。
否则的话， 从服务器就要执行完整重同步操作。
配置从服务器，设置 slaveof ip port 就可以了，也可以不改配置文件，直接在命令行执行。
从服务器的只读模式通过 slave-read-only 配置。默认开启、 >>>主服务器的配置项。
从服务器可以通过 masterauth 配置主服务器的密码
持久化
redis持久化有两种方式，AOF&RDB
rdb持久化可以在指定的时间间隔内生成数据集的时间点快照。
AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
RDB优点：适合备份，一个时间段的数据集，这个特别像MySQL复制的按行复制。恢复的速度比AOF的快。
RDB确定：RDB保存的是整个数据集的状态，所以它并不是一个轻松的操作， 比如5分钟执行一次，那么还会至少丢这五分钟的数据。
每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。
save 60 1000 保存快照的频率。
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
把快照存储在名为dump.rdb的文件中
AOF优点：
AOF可以设置不同的fsync策略
AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF缺点：
对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。
appendonly yes 打开AOF
每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。
这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
AOF重写
AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。
比如：执行100次 incr命令，最后结果是加了100，没必要记录100次。
以下是 AOF 重写的执行步骤：
Redis 执行 fork() ，现在同时拥有父进程和子进程。
子进程开始将新 AOF 文件的内容写入到临时文件。
对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
AOF持久化频率
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。
有三个选项：
每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
如果AOF文件在写入时出现问题，redis-check-aof --fix 使用这个命令来恢复。
执行如下命令切换RDB---->AOF
redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save ""
redis会优先使用aof方式恢复数据集。
RDB就是Redis的备份方式。
sentinel管理多个Redis服务器(哨兵)
sentinel执行三个任务：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
sentinel 是一个分布式系统，可以运行多个sentinel进程。这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
对于 redis-sentinel 程序， 你可以用以下命令来启动 Sentinel 系统：
redis-sentinel /path/to/sentinel.conf
对于 redis-server 程序， 你可以用以下命令来启动一个运行在 Sentinel 模式下的 Redis 服务器：
redis-server /path/to/sentinel.conf --sentinel
两种方法都可以启动一个 Sentinel 实例。
启动 Sentinel 实例必须指定相应的配置文件， 系统会使用配置文件来保存 Sentinel 的当前状态， 并在 Sentinel 重启时通过载入配置文件来进行状态还原。
如下是一个sentinel 所需的最少配置。
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。
换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
sentinel <选项的名字> <主服务器的名字> <选项的值>
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记为主观下线。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
每个sentinel都需要定期执行的任务
每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。
自动发现 Sentinel 和从服务器
一个 Sentinel 可以与其他多个 Sentinel 进行连接， 各个 Sentinel 之间可以互相检查对方的可用性， 并进行信息交换。
你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址， 因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ， 这一功能是通过向频道 __sentinel__:hello 发送信息来实现的。
与此类似， 你也不必手动列出主服务器属下的所有从服务器， 因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。
每个 Sentinel 会以每两秒一次的频率， 通过发布与订阅功能， 向被它监视的所有主服务器和从服务器的 __sentinel__:hello 频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。
每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 __sentinel__:hello 频道， 查找之前未出现过的 sentinel （looking for unknown sentinels）。 当一个 Sentinel 发现一个新的 Sentinel 时， 它会将新的 Sentinel 添加到一个列表中， 这个列表保存了 Sentinel 已知的， 监视同一个主服务器的所有其他 Sentinel 。
Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。 如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧， 那么这个 Sentinel 会立即升级到新配置上。
在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口号）的 Sentinel ， 如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。
还有个TILT模式，这个是sentinel 依赖计算机时间，如果时间出问题，sentinel应该保持在TILT模式，而不是继续正常工作。
当 Sentinel 进入 TILT 模式时， 它仍然会继续监视所有目标， 但是：
它不再执行任何操作，比如故障转移。
当有实例向这个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令时， Sentinel 返回负值： 因为这个 Sentinel 所进行的下线判断已经不再准确。
如果 TILT 可以正常维持 30 秒钟， 那么 Sentinel 退出 TILT 模式。
>>>>>>>>>>>>>>>>>redis 集群实际上就是一个高可用手段和负载手段。