前言
之前简单分享了一下单机版Redis。包括：
- 为什么用 Redis 以及为什么不用 Redis
- Redis 为什么这么快
- Redis 的数据结构
- Redis 单线程吞吐量高的原因
单机版 Redis 响应快、支持的并发量高，如果有持久化的内存，甚至还能做到数据不丢失。那我们可以直接使用单机版 Redis 作为数据库吗？
假设我们使用单机版 Redis 作为存储介质。Redis 一般分为两种用途，缓存和持久化数据库。
我们先看最常见的一种情况，断电/重启：
- 业务数据库： 使用持久化内存可以保证重启后数据不丢失。但是断电的过程中整个业务没有数据源就会瘫痪掉。
- 缓存： 如果缓存断电瘫痪，倒不至于会对业务造成直接瘫痪，毕竟业务数据库中有完整的数据。如果 Redis 宕机，就会导致缓存雪崩——所有缓存都失效，所有的请求都是直接打到数据库，导致数据库压力激增，导致服务响应时间增加。
在断电情况下，单机 Redis 作为业务数据库肯定是不满足条件的；作为缓存，如果数据量小、请求量少的话，并不是很影响业务使用（这种场景也没有用缓存的必要）。
那如果不考虑重启的情况，单机 Redis 就没问题了吗？
数据量、访问量小的情况下，貌似确实不会有什么问题，我们还是考虑数据量、访问量大的情况。
比如现在有一个单机 redis， 需要存储几亿个key。当 Redis 持久化时，如果数据量增加，需要的内存也会增加，主线程 fork 子进程时就可能会阻塞。即使在内存、CPU资源充足的情况下，一次数据备份就要消耗很长时间，导致 Redis 的服务不可用。
不过，如果你不要求持久化保存 Redis 数据，那么，增加cpu的硬件性能和内存容量会是一个不错的选择。但是这样又有第二个问题，就是硬件成本问题：一块128G的内存条的价格远大于四块32G 的内存条的价格之和，cpu也是同理。硬件的成本会随着性能的不断提高呈指数上升
综上所述，单机版 Redis 主要存在以下两个问题：
- 可用性（断电后，业务不可用）
- 数据臃肿（单机CPU对大量数据的操作）
- 备份阻塞导致服务不可用
- 成本指数增长
那怎么办呢？单机不够用，就多加几台机器嘛！下面我们来看一下 Redis 提供的在多机环境下几种常见的资源使用策略，看看能否解决上述的两个问题
一、主从同步(Master-Slave)
主从同步就是，多个 Redis 节点，一个主节点（master），多个副节点（slave）。读请求会发送到各个节点，写请求只会发给 master，然后 slave 定时会从 master 拉取新增的写操作以保证数据的一致性。
那如何从单机版加一个 slave 节点过渡到主从模式呢？ 例如，现在有实例 1（ip：192.168.19.3）和实例 2（ip：192.168.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：
replicaof 192.168.19.3 6379
第一次请求到 master 的 RDB 文件全量同步，在 RDB 文件内容之后的操作都是增量同步进行。
之后就是重复1和3的过程。
二、哨兵机制(Sentinel)
上面讲的主从同步只是保证了 Redis 的数据有及时备份。可以分担一部分主库的访问压力，以及保证了从库的可用性。但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。
哨兵（Sentinel）就是为了解决这个问题而产生的。它实现了主从库自动切换的关键机制，它有效地解决了主从复制模式下故障转移的三个问题。
- 主库真的挂了吗？
- 该选择哪个从库作为主库？
- 怎么把新主库的相关信息通知给从库和客户端呢？
下面我们就从这三个问题来看 Sentinel 对应的三种职能，监控、选主和通知。
2.1 监控
哨兵需要判断主库是否处于下线状态。这里要先说两个概念，即主观下线和客观下线，
哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库响应超时了，那么，哨兵就会先把它标记为“主观下线”。如果检测的是从库，那么，哨兵简单地把它标记为主观下线就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。
如果检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”。因为很有可能存在这么一个情况：那就是哨兵误判了，其实主库并没有故障。可是，一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算和通信开销。
那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断的时候，经常会和家人或朋友一起商量一下，然后再做决定。哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。
“客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。
2.2 选主
当哨兵们判断主库客观下线的时候，就要开始下一个决策过程了，即从许多从库中，选出一个从库来做新主库。
一般来说，我把哨兵选择新主库的过程称为“筛选 + 打分”。
筛选条件： 网络连接状态（现在 + 之前）。在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
打分：
- 首先，优先级最高的从库得分高。用户可以手动设置从库的优先级。
- 其次，和旧主库同步程度最接近的从库得分高。
- 最后，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。
哨兵也是集群模式，也要保证服务的可用性，所以也会有相应的保证机制。这里不在本篇的 Redis 集群讨论范围之内，所以就不展开描述了。
三、 Redis Cluster
看到这里，还记得我们一开始发现的 Redis 单机版的两个问题吗？可用性和数据臃肿。
上面主从模式 + 哨兵模式足以保证 Redis 服务的可用性，但是看起来并没有解决数据臃肿的问题， Redis Cluster 就为我们提供了解决这个问题的方案。
3.1 数据切片
切片集群，也叫分片集群，就是指启动多个 Redis 实例组成一个集群，然后按照一定的规则，把收到的数据划分成多份，每一份用一个实例来保存。
这样单份数据可以缩小到备份不影响该实例的主进程，而且还可以解决硬件成本问题。
那数据都分散了，用户需要查某一条数据，Redis 怎么知道这条数据在哪个实例呢？
我们要先弄明白切片集群和 Redis Cluster 的联系与区别。 切片集群是一种保存大量数据的通用机制，这个机制可以有不同的实现方案。 Redis Cluster 方案采用 hash 槽（Hash Slot，接下来我会直接称之为 Slot），来处理数据和实例之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个 hash 槽，这些 hash 槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个 hash 槽中。具体的映射过程分为两大步：
- 首先根据键值对的 key，按照CRC16 算法计算一个 16 bit 的值；
- 然后，再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的 hash 槽。
关于 CRC16 算法，不是我们讨论的重点。我们只需要每一个 key 都能算出来一个 0~16383 的数就好。
每一个 0~16383 的数被称为一个slot（槽）。一个 Redis 实例有多个槽，集群中的所有 Redis 实例的槽加起来一定等于 16384。换句话说，在手动分配 hash 槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。
3.2 客户端如何定位数据？
在定位键值对数据时，它所处的 hash 槽是可以通过计算得到的，这个计算可以在客户端发送请求时来执行。但是，要进一步定位到实例，还需要知道 hash 槽分布在哪个实例上。
Redis 实例会把自己的 hash 槽信息发给和它相连接的其它实例，来完成 hash 槽分配信息的扩散，Redis集群采用P2P的Gossip(流言)协议， Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息，这种方式类似流言传播 当实例之间相互连接后，每个实例就有所有 hash 槽的映射关系了。相当于每一个实例都有一份 slot 与实例地址的映射关系表。
当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有这个键值对映射的 hash 槽，那么，这个实例就会给客户端返回下面的 MOVED 命令响应结果，这个结果中就包含了新实例的访问地址。
GET hello:key
(error) MOVED 13320 192.168.19.5:6379
如上图，用户连接上任意一个 Redis 实例，都可以查询集群中所有的key。比如连上实例2，查询key = “hello”。实例2会根据key计算 hash 槽的值。
- 如果槽就在实例2上，则直接查询结果返回；
- 如果不在实例2上，则返回存在key的实例地址。
客户端也会缓存请求过的key对应实例的地址。
如果实例槽有变动，比如手动增删了几个实例，剩下的实例还是可以自动同步新的 hash 槽对应的实例位置。
3.3 实际应用
Redis Cluster 模式解决了数据臃肿的问题，但是单独的 Redis Cluster 模式并没有可用性，如果任意一个实例断电或者断网，这个实例所有 hash 槽的数据就会处于不可用的状态。
所以在实际使用场景下，上述的三种集群模式都会结合起来。
到这里我们就解决了开篇提出的两个问题。
- 保证可用性： cluster node 中的主从同步和哨兵选举机制
- 避免数据臃肿：cluster node 集群的数据切片
四、小结
开篇我们提出的单机版 Redis 作为数据库的两个弊端。然后介绍了 Redis 官方的集群方案分别是如何解决这两个弊端的。
其实除了 Redis 官方提供的集群方案，也有很多优秀的开源 Redis 集群方法。 比如：
推特的 twemproxy
这两种开源方案和 Redis 官方的集群方案最大的区别就是数据节点的管理方式。
- Redis 是去中心化，hash 槽和节点的映射每个节点都会有保存，通过 Gossip 协议传播；
- 这两种方案是中心化。有单独的代理节点管理hash 槽和节点的映射。
那去中心化和中心化我们又该如何选择呢？