Redis

非关系性数据库NoSQL:Redis

CAP+BASE

传统的ACID

• Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
• Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
• Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
• Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

CAP

• C: Consistency(强一致性)
• A: Availability（可用性）
• P: Partition tolerance（分区容错性）

因此，根据CAP原理将NoSQL数据库分成满足CA、CP、AP原则三大类

• CA - 传统数据库。单点集群，满足一致性，可用性的系统，在可扩展性上不太强。
• CP - Redis、Mongodb。 满足一致性，分区容忍性的系统，性能不是特别高。
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。(大多数网站架构的选择)

CAP的3进2

• CAP理论就是在分布式存储系统中，最多只能实现上面的两点。由于网络硬件肯定会出现延迟丢包等问题，分区容错性是我们必须需要实现的。
• 只能在一致性 C 和 可用性 A 之间进行权衡，没有NoSQL系统能同时保证这三点。

BASE

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案

• 基本可用 Basically Available
• 软状态 Soft State
• 最终一致 Eventually Consistent

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

Redis的特点

• Redis支持数据的持久化，可以将内存中的数据(支持异步)保持在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的 key-value 类型的数据，同时还提供 string，list，set，zset，hash 等数据结构的存储。
• Redis支持数据的备份，即 master-slave 模式的数据备份。

Redis基础知识

• Redis 是单进程
• 默认16个数据库，类似数组下表从 0 开始，初始默认使用 0 号库。
• select ：命令切换数据库。SELECT 7 ——> 选择 6号库。
• dbsize ：查看当前数据库的key的数量。 keys *：查看所有的 key。(支持占位符 key k?)
• flushdb：清空当前库。
• flushall：通杀全部库。
• 统一密码管理，16个库都是同样密码，要么都OK要么一个也连接不上。
• Redis 索引都是从 0 开始。
• 默认端口是6379 (9宫格键盘 merz)。

Redis数据类型

Redis 键(key)

• keys * 查看所有的 key。
• exists key： 判断某个key是否存在。
• move key db： 把当前 key 移动到指定 DB (当前库就没有了)。
• expire key 秒钟： 为给定的key设置过期时间。
• ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期。(过期移除内存系统)
• type key： 查看你的key是什么类型。

String（字符串）

• string 是 redis 最基本的类型，可以理解成与Memcached一样的类型，key：value。
• string 类型是二进制安全的。意思是redis的string可以包含任何数据。比如序列化的对象…
• string 一个redis中字符串 value 最多可以是512M。
• 单值 单value

常用命令：

• set/get/del/append/strlen 设置、获取、删除、追加、获取长度。

• incr/decr/incrby/decrby： 一定要是数字才能进行加减。

• getrange： 获取指定区间范围内的值，截取字符串。从0到-1表示全部。

• setrange： 设置指定区间范围内的值，插入字符串。格式是setrange key值 具体值。对指定位置 覆盖操作。

• setex(set with expire)键秒值： 对该key设置存活时间。setex k1 10 v1

• setnx(set if not exist)： 如果key值存在返回0，如果不存在进行set设置值。setnx k1 v1

• mset： 合并set。mset k1 v1 k2 v2 k3 v3

• mget： 合并get。gset k1 k2 k3

• msetnx： mset k1 v1 k2 v2 如果 k1 已经存在了。全部set失败！
• getset(先get再set)： 获取输出当前value值，然后set。

hash（哈希，类似Java里的Map）

• Redis hash 是一个键值对集合。
• Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象 类似Java里面的 Map< String,Object>
• K/V模式不变，但V是一个键值对。

常用命令：

• hset/hget： hset KEY_NAME name zs hget KEY_NAME name
• hmset/hmget： hmset KEY_NAME id 11 name zs hmget KEY_NAME id name
• hgetall/hdel： hgetall KEY_NAME hdel KEY_NAME name
• hexists： 用于查看哈希表的指定字段是否存在。hexists KEY_NAME id
• hkeys/hvals： 用于获取哈希表中的所有域（key）,返回哈希表所有域(value)的值。hkeys KEY_NAME hvals KEY_NAME
• hincrby/hincrbyfloat： 用于为哈希表中的字段值加上指定增量值。hincrby user id
• hlen： 获取哈希表中字段的数量。hlen KEY_NAME
• hsetnx： 用于为哈希表中不存在的的字段赋值。hsetnx KEY_NAME key value v1

list（列表）

• Redis 列表是简单的字符串列表，按照插入顺序排序。
  • 你可以添加一个元素列表的头部（左边）或者尾部（右边）。
• 底层实际是个链表
• 单值多value

常用命令：

• lpush/rpushlpop/rpop/lrange

• lindex： 按照索引下标获得元素(从上到下)。LINDEX KEY_NAME 1

• llen： 获取长度。 LLEN KEY_NAME
• lrem： 删2个1。LREM KEY_NAME 2 1
• ltrim： 开始index 结束index，截取指定范围的值后再赋值给key。LTRIM KEY_NAME 3 5

set（集合）

• Redis 的Set是string类型的无序集合，且不允许重复的成员。它是通过HashTable实现实现的。
• 单值多value

常用命令：

• sadd： 将一个或多个成员元素加入到集合中，已经存在于集合的成员元素将被忽略。sadd KEY_NAME v1
• del： 删除集合。del KEY_NAME
• smembers： 命令返回集合中的所有的成员。不存在的集合 set 被视为空集合。smembers KEY_NAME
• srandmember： srandmember KEY_NAME value 从集合中随机出几个数。
• sismember： 判断成员元素是否是集合的成员。sismember KEY_NAME 1
• scard： 返回集合中元素的数量。scard KEY_NAME
• srem： 删除集合中元素。srem KEY_NAME value
• spop： 随机集合中一个value出栈。spop KEY_NAME
• smove： 将指定成员 member 元素从 source 集合移动到目标集合。smove set01 set02 value
• 数学集合类
  • 差集：sdiff 返回在KEY_NAME01里面，不在set02里面的 value。
    • sdiff KEY_NAME01 KEY_NAME02
  • 交集：sinter 返回在KEY_NAME01里面，也在set02里面的 value。
    • sinter KEY_NAME01 KEY_NAME02
  • 并集：sunion 返回去重后的集合。

zset(sorted set：有序集合)

• Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
• 不同的是每个元素都会关联一个整数或者双精度浮点数的分数。(比如游戏分数)
• redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。
• 在set基础上，加一个score值。之前set是k1 v1 v2 v3，现在 zset是k1 score1 v1 score2 v2

常用命令：

• zadd： 用于将一个或多个成员元素及其分数值加入到有序集中。zadd KEY_NAME 60 v1 70 v2

• zrange： ZRANGE KEY_NAME 0 -1 | ZRANGE KEY_NAME 0 -1 withscores

• zrangebyscore：返回有序集合中指定分数区间的成员列表。

  zrangebyscore KEY_NAME 开始score 结束score withscores

  • zrangebyscore zset 10 (50 不包含50。
  • zrangebyscore zset 10 (50 limit 2 2 limit 返回限制,limit 开始下标走多少步。

• zrem： 用于移除有序集中的一个或多个成员，不存在的成员将被忽略。zrem KEY_NAME value

• zcard： 用于计算集合中元素的数量。ZCARD KEY_NAME

• zcount： 用于计算有序集合中指定分数区间的成员数量。ZCOUNT KEY_NAME min max

• zrank： 作用是获得下标值。zrank KEY_NAME value

• zscore： 对应值,获得分数。 zscore KEY_NAME value

• zrevrank： 作用是逆序获得下标值。 zrevrank KEY_NAME value

• zrevrange： 返回有序集中，指定区间内的成员。其中成员的位置按分数值递减(从大到小)来排列。ZREVRANGE key 0 -1 [WITHSCORES]

• zrevrangebyscore： 返回有序集中指定分数区间内的所有的成员。有序集成员按分数值递减(从大到小)的次序排列。

redis.conf配置文件

GENERAL 通用

• daemonize yes：是否将Redis作为守护进程运行
• pidfile：当Redis以守护进程方式运行时，Redis默认会把pid写入 /var/run/redis.pid文件。
• port：6379 端口号。
• tcp-backlog：设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
• timeout：超时断开连接。(0 to disable)
• bind：端口的绑定。
• tcp-keepalive：单位为秒，设置为60s (0即为不检测)
• loglevel：日志级别,debug、verbose、notice、warning。
• logfile：指定日志文件名，为空则标准输出。
• syslog-enabled：是否把系统日志输出到syslog中，默认关闭
• syslog-ident：日志鉴别，日志以 redis 开头。
• syslog-facility：指定syslog设备，值可以是USER或 LOCAL0-LOCAL7。默认为 LOCAL 0
• databases 16：默认为 16 个库。

SNAPSHOTTING快照

• Save：save <seconds> <changes>

• Redis 默认配置文件中提供了三个条件 触发 RDB 保存：

  • save 900 1 ：——> 900s（15min）至少有 1 次 key 的改动。
  • save 300 10 ：——> 300s（5min）至少有 10 次 key 的改动。
  • save 60 10000 ：——> 60s（1min）至少有 10000 次 key 的改动。
  • 直接输入 save 或者是 bgsave 命令，即刻备份！
    • Save：save时只管保存，其它不管，全部阻塞。
    • BGSAVE：会在后台异步进行快照操作，快照同时还可以响应客户端请求。
      • 可以通过 lastsave 命令获取最后一次成功执行快照的时间。
• 禁用 RDB： save “” (不设置任何save指令，或者给save传入一个空字符串参数)。
• stop-writes-on-bgsave-error：yes
  • 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制。
• rdbcompression：
  • 对于存储到磁盘中的快照，可以设置是否进行压缩存储。
  • 如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
• rdbchecksum
• 在存储快照后，还可以让redis使用CRC64算法来进行数据校验。
• 但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
• dbfilename dump.rdb
  • 指定本地数据库文件名，默认值为dump.rdb。
• dir：config get dir (获取目录)

SECURITY 安全

• 访问密码的查看、设置和取消
• 127.0.0.1：6379 > config get requirepass (获取密码)
• 127.0.0.1：6379 > config set requirepass “123456” (设置密码) ping 不通了。
• 127.0.0.1：6379 > auth 123456 （输入密码）

• LIMITS 限制

• maxclients 10000： redis同时可以与多少个客户端进行连接，默认情况为10000个客户端。

• maxmemory： 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
• maxmemory-policy：
  1. volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
  2. volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
  3. volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
  4. allkeys-lru：从数据集中挑选最近最少使用的数据淘汰。
  5. allkeys-random：从数据集中随机选择数据淘汰。
  6. no-enviction（驱逐）：永不过期，不进行移除。针对写操作，只是返回错误信息。禁止驱逐数
  7. volatile-lfu： 使用具有过期集的键之间的近似LFU(数据过去被访问多次，那么将来被访问的频率也更高)将访问频率最少的键值对淘汰。
  8. allkeys-lfu：从数据集中近似LFU(将访问频率最少的键值对淘汰。)选择数据淘汰。
• maxmemory-samples： 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小。
  • redis默认会检查这么多个key并选择其中LRU的那个。

持久化

RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis 会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了再用这个临时文件替换上次持久化好的文件

fork 的作用是复制一个与当前进程一样的进程。

• 新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

RDB 保存的是 (默认) dump.rdb 文件，可以在 redis.conf中配置

优势

• 整个过程中，主进程是不进行任何IO操作的，确保了极高的性能 适合进行大规模数据的恢复。
• 如果对于数据恢复的 完整性 不是非常敏感，那RDB方式要比AOF方式更加的高效。

劣势

• 整个过程中，主进程是不进行任何IO操作的，确保了极高的性能 适合进行大规模数据的恢复。
• 如果对于数据恢复的 完整性 不是非常敏感，那RDB方式要比AOF方式更加的高效。

修复

• 如果 RDB 文件有错误 在安装目录下，用 redis-check-rdb 对 RDB 文件进行修复，把错误的命令全部删除。
• redis-check-rdb –fix dump.rdb

停止

• 动态停止所有RDB保存规则的方法：redis-cli config set save “”

AOF

快照并不是很可靠。如果你的电脑突然宕机了，或者电源断了，又或者不小心杀掉了进程，那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时，就会把命令追加到AOF文件里，当你重启Redis时，AOF里的命令会被重新执行一次，重建数据。

启用AOF

把配置项appendonly（默认为false）设为yes：

appendonly yes

文件路径和名称

# 文件存放目录，与RDB共用。默认为当前工作目录。
dir ./

# 默认文件名为appendonly.aof
appendfilename "appendonly.aof"

可靠性

你可以配置Redis调用fsync的频率，有三个选项：

• 每当有新命令追加到AOF的时候调用fsync。速度最慢，但是最安全。
• 每秒fsync一次。速度快（2.4版本跟快照方式速度差不多），安全性不错（最多丢失1秒的数据）。
• 从不fsync，交由系统去处理。这个方式速度最快，但是安全性一般。

推荐使用每秒fsync一次的方式（默认的方式），因为它速度快，安全性也不错。相关配置如下：

# appendfsync always
appendfsync everysec
# appendfsync no

日志重写

随着写操作的不断增加，AOF文件会越来越大。例如你递增一个计数器100次，那么最终结果就是数据集里的计数器的值为最终的递增结果，但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录，只需要1个命令就行了，也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能：在不中断服务的情况下在后台重建AOF文件。

工作原理如下：

• Redis调用fork()，产生一个子进程。
• 子进程把新的AOF写到一个临时文件里。
• 主进程持续把新的变动写到内存里的buffer，同时也会把这些新的变动写到旧的AOF里，这样即使重写失败也能保证数据的安全。
• 当子进程完成文件的重写后，主进程会获得一个信号，然后把内存里的buffer追加到子进程生成的那个新AOF里。

我们可以通过配置设置日志重写的条件：

# Redis会记住自从上一次重写后AOF文件的大小（如果自Redis启动后还没重写过，则记住启动时使用的AOF文件的大小）。
# 如果当前的文件大小比起记住的那个大小超过指定的百分比，则会触发重写。
# 同时需要设置一个文件大小最小值，只有大于这个值文件才会重写，以防文件很小，但是已经达到百分比的情况。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

要禁用自动的日志重写功能，我们可以把百分比设置为0：

auto-aof-rewrite-percentage 0

Redis 2.4以上才可以自动进行日志重写，之前的版本需要手动运行BGREWRITEAOF这个命令。

数据损坏修复

如果因为某些原因（例如服务器崩溃）AOF文件损坏了，导致Redis加载不了，可以通过以下方式进行修复：

• 备份AOF文件。

• 使用redis-check-aof命令修复原始的AOF文件：

  $ redis-check-aof --fix

• 可以使用diff -u命令看下两个文件的差异。

• 使用修复过的文件重启Redis服务。

优点

• 比RDB可靠。你可以制定不同的fsync策略：不进行fsync、每秒fsync一次和每次查询进行fsync。默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
• AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。
• 当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis会把新旧文件进行切换，然后开始把数据写到新文件上。
• AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，然后重启服务，这样就能把被刷掉的数据恢复回来。

缺点

• 在相同的数据集下，AOF文件的大小一般会比RDB文件大。
• 在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。
• 在过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题。

小结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾

同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据。
• AOF 文件保存的数据集要比 RDB 文件保存的数据集要 完整 RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。

---

• 那要不要只使用AOF呢？
  • 因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

性能建议

因为 RDB 文件只用作后备用途，建议只在Slave上持久化RDB文件，只要15分钟备份一次就够了，只保留 save 900 1 这条规则。

• 如果开启 Enalbe AOF
  • 好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO。二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
• 如果不开启 Enable AOF
  • 仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果 Master/Slave 同时down掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。

Redis事务

• 一个队列中可以一次性，顺序性执行多个命令，本质是一组命令的集合。
• 一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。
• 没有隔离级别的概念。不保证原子性，没有回滚。

命令

• MULTI： 标记一个事务块的开始。OK
• EXEC： 执行所有事务块内的命令。
• DISCARD： 取消事务，放弃执行事务块内的所有命令。
• UNWATCH： 取消 WATCH 命令对所有 key 的监视。一旦执行了exec，之前加的监控锁都会被取消掉了。
• WATCH： 监视一个或多个 key；如果在事务执行之前这个 key 被其他命令所改动，事务将被打断。

Case1 正常执行： MULTI 一系列操作 EXEC
Case2 放弃事务： MULTI 一系列操作 DISCARD
Case3 全体连坐： MULTI 一系列操作中有错误操作（直接报错的命令） EXEC（全部失败）
Case4 冤头债主： MULTI 一系列操作中有错误操作（不直接报错的命令，比如 incr 字符串） EXEC （错误命令不执行）
Case4 watch监控： 先监控 在开启事务。watch key 、MULTI 一系列操作 EXEC 如果其他线程没有干扰则成功，反之失败。

• 悲观锁/乐观锁/CAS(Check And Set)
  • 悲观锁： 行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
  • 乐观锁： 读写不会上锁。但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
• Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，整个事务队列都不会被执行。
• 通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

Redis 的复制(Master/Slave)

• 主从复制 读写分离 容灾恢复。配从不配主
• 主机数据更新后根据配置和策略，自动同步到备机的 master/slaver 机制，Master以写为主，Slave以读为主。
• info replication 查看 role 角色。

一主二仆

info replication： 返回主从复制的信息。主机才可以写，从机只能读。

从库配置：slaveof 主库IP 主库端口 slaveof 127.0.0.1 6379

• 如果 master shutdown 后，从库 role 还是 slave。 master 恢复上线，关系也恢复。
• 每次 slave shutdown 与 master 断开之后，都需要重新连接，除非你配置进redis.conf文件。
  • 从库每次 slave shutdown 后 role 变为 master。
• info replication 查看 role 角色。

薪火相传

上一个 Slave 可以是下一个 Slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求。减轻主 Master 压力。

• 中途变更转向：会清除之前的数据，重新建立拷贝最新的。
• slaveof 新主库IP 新主库端口 slaveof 127.0.0.1 6379

反客为主

上一个 Slave 可以是下一个 Slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求。减轻主 Master 压力。

• 中途变更转向：会清除之前的数据，重新建立拷贝最新的。
• slaveof 新主库IP 新主库端口 slaveof 127.0.0.1 6379

哨兵模式(反客为主自动版本)

• 能够后台自动监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

原有体系 主仆关系
1、新建一个文件名为 sentinel.conf 空 配置文件。
2、配置 sentinel.conf文件。写入 sentinel monitor 被监控数据库名字 127.0.0.1 6379 1

• 上面最后一个数字1，表示主机挂掉后 salve 投票看让谁接替成为主机，得票数多成为主机。
  3、启用 redis-sentinel /myredis/sentinel.conf 监控。
  4、如果 主Master shutdown 以后，salve 投票多的选为 新Master，而剩余 salve 转向 新Master。
  5、即便 主Master恢复，原来的体系已经建立，由于监控则变成新Master 的 salve
  6、一组sentinel能同时监控多个Master。

缺点

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，
• 所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。