Redis一主多从
和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。
一个最经典的Redis单体架构是这样的：一主二从的模式，以实现读写分离。
- master节点：提供写服务
- slave节点：提供读服务
主从复制过程：
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
无磁盘化复制：
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。
Redis哨兵
Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是 Redis 高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。
一主多从有个弊端：一旦master节点挂掉后，slave节点是不能提供一个写服务的。
为了保证Redis的可用性，就引入了哨兵。哨兵可以是一个也可以是多个，这里介绍一个经典的一主二从三哨兵的场景：
这里每一个哨兵都会对master和slave做一个监控，现在如果master挂掉：
哨兵1检测到了，但是此时不能去切换这个master，因为网络可能会有波动，哨兵1检测master挂掉，但是如果仅仅是网络波动，也会表明是挂掉的，在网络波动里，哨兵2和哨兵3也许检测到master仍然存活，所以仅仅靠一个哨兵是不能决定master存活与否的。
这里就引入了少数服从多数的机制，如果哨兵里面一半以上检测到了master挂掉，那么就开始切换master。
现在就需要选举learder，也是通过哨兵来进行少数服从多数的投票，来将slave变成master。新上任的master需要和剩下的slave进行同步。
最后当前任master恢复后，会成为slave，并与现任master同步。
tips:
- 所以，哨兵的部署一定要分布式的部署在不同的节点，其健壮性才能更高。
- 哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧，这个时候master挂了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。
Redis集群
下面是三主三从的模式：
特点
- 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在与一个集群环境中，他们彼此之间可以交互和通信，比如ping pong。那么这些关系都会保存到某个配置文件中，每个节点都有，这个我们在搭建的时候会做配置的。
- 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
- 某个节点挂了，也是通过超过半数的节点来进行的检测，客观下线后主从切换，和我们之前在哨兵模式中提到的是一个道理。
Redis中存在很多的插槽，又可以称之为槽节点，用于存储数据。
Redis通过Hash函数来决定数据会被存储到哪个redis节点或者从哪个redis节点读取数据。每个节点包含了多个槽，数据也就是保存在这些槽上的。如下图所示：
