4种模式
- 1. 单机
- 1.1 优点
- 1.2 缺点
- 2. 主从
- 2.1 优点
- 2.1 缺点
- 3. 哨兵
- 3.1 优点
- 3.2 缺点
- 3.3 哨兵模式监控的原理
- 4. 集群
- 4.1 数据分片
- 4.2 数据分片之后怎么查，怎么写？
- 4.3 如何做到水平扩展？
- 4.4 如何做故障转移？
1. 单机
安装一个redis，启动起来，业务调用即可。
1.1 优点
部署简单。
高性能，单机不需要同步数据，数据天然一致性。
1.2 缺点
可靠性保证不是很好，单节点有宕机的风险。
2. 主从
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。
前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。
2.1 优点
一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
分担主节点读压力。
2.1 缺点
一旦 主节点宕机，从节点 晋升成 主节点，同时需要修改 应用方 的 主节点地址，还需要命令所有 从节点 去 复制 新的主节点，整个过程需要 人工干预。
主节点 的 写能力、存储能力 受到 单机的限制。
3. 哨兵
刚刚提到了，主从模式，当主节点宕机之后，从节点是可以作为主节点顶上来，继续提供服务的。但是有一个问题，主节点的IP已经变动了，此时应用服务还是拿着原主节点的地址去访问，这…
于是，在Redis 2.8版本开始引入，就有了哨兵这个概念。在复制的基础上，哨兵实现了自动化的故障恢复。
如图，哨兵节点由两部分组成，哨兵节点和数据节点：
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
- 数据节点：主节点和从节点都是数据节点。
访问redis集群的数据都是通过哨兵集群的，哨兵监控整个redis集群。
Redis的Sentinel最小配置是 一主一从。
3.1 优点
主从可以自动切换，系统更健壮，可用性更高。
3.2 缺点
Redis较难支持在线扩容，对于集群，容量达到上限时在线扩容会变得很复杂。
3.3 哨兵模式监控的原理
- 一般情况下， 每个 Sentinel 会以每 10秒一次的频率，向它已知的所有 主服务器 和 从服务器 发送 INFO 命令；如果某个服务器距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线。
- 当一个 主服务器 被 Sentinel标记为 主观下线 时，Sentinel 向 下线主服务器 的所有 从服务器 发送 INFO 命令的频率，会从10秒一次改为 每秒一次。
- 当有足够数量 的 Sentinel（至少要达到配置文件指定的数量）在指定的 时间范围 内同意这一判断，那么这个该主服务器被标记为 客观下线。这时候投票自动选出新的主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制。
4. 集群
主从不能解决故障自动恢复问题，哨兵已经可以解决故障自动恢复了，那到底为啥还要集群模式呢？
主从和哨兵都还有另外一些问题没有解决，单个节点的存储能力是有上限，访问能力是有上限的。
集群模式就是把数据进行分片存储，当一个分片数据达到上限的时候，就分成多个分片。
4.1 数据分片
集群的键空间被分割为16384个slots（即hash槽），通过hash的方式将数据分到不同的分片上的。
4.2 数据分片之后怎么查，怎么写？
读请求分配给slave节点，写请求分配给master，数据同步从master到slave节点。
读写分离提高并发能力，增加高性能。
4.3 如何做到水平扩展？
master节点可以做扩充，数据迁移redis内部自动完成。
当你新增一个master节点，需要做数据迁移，redis服务不需要下线。
举个栗子：上面的有三个master节点，意味着redis的槽被分为三个段，假设三段分别是07000，700112000、12001~16383。
现在因为业务需要新增了一个master节点，四个节点共同占有16384个槽。
槽需要重新分配，数据也需要重新迁移，但是服务不需要下线。
redis集群的重新分片由redis内部的管理软件redis-trib负责执行。redis提供了进行重新分片的所有命令，redis-trib通过向节点发送命令来进行重新分片。
4.4 如何做故障转移？
假如途中红色的节点故障了，此时master3下面的从节点会通过 选举 产生一个主节点。替换原来的故障节点。
此过程和哨兵模式的故障转移是一样的。
