集群
与普通应用集群类似，Redis集群主要解决两个问题：
- 结构上的单点故障，采用主从架构
- 容量上内存瓶颈，对数据进行分片，保存在不同的主机，即cluster
主从复制
Redis本身提供了replication的功能，可以实现主Redis服务器到从Redis服务器的数据复制。
读写分离：主服务器进行读写操作，从数据库只能进行读取操作（其实也可以通过配置slave-read-only为no，开启写功能，但是没什么意义，最终还是会被主的数据覆盖）。
可以为从服务器在添加从服务器，形成分层结构。
主从复制的原理
1、复制初始化阶段：从redis服务器向主服务器发送SYNC（2.8版本后使用PSYNC），主服务器接收到命令后开始进行持久化RDB备份操作，操作期间的命令放在缓存中，备份完成后将RDB数据和缓存中的数据一起发送给从服务器。
2、复制同步阶段：主服务器接收到新的写入数据的同时向从服务器写入（积压队列的原理）。
配置主从
Redis配置主从模式很简单。
- 主服务器无需任何修改
- 从服务器的配置文件中配置
slaveof 主redisIP或域名 主redis端口号即可,如果配置了密码保护，需要在配置文件中添加masterauth 主redis的密码
也可以通过redis-cli命令行中执行SLAVEOF 主IP 主PORT，命令SLAVEOF NO ONE表示告诉自己没有主节点。
配置完成后可以使用INFO replication命令查看服务器状态信息。
从数据库持久化
主从模式搭建完成后，禁用主服务器的持久化，开启从服务器的持久化。
优点：提高主服务器的性能。
缺点：维护麻烦。
如果主服务器故障时，需要手动通过从服务器恢复主服务器数据，操作流程：
1、使用SLAVEOF NO ONE命令将从服务器提升为主；
2、在主服务器上执行SLAVEOF将自己设置成新主服务器的从服务器。
注意：故障的主服务器不能重启，不能使用supervisor管控
无盘复制
主服务器完全不使用持久化，需要关闭所有的RDB规则的同时配置repl-diskless-sync yes，测试阶段。
哨兵（sentinel）
主从集群主要起到了数据冗余、读写分离的作用，但是如果出现主服务器故障的问题，不能快速发现且需要人工去切换主从节点。
而哨兵则可以完成对主从服务器的监控和主从自动切换。
特点：
- 一个哨兵可以监控多个主从Redis集群
- 一个主从Redis集群可以被多个哨兵监控
- 哨兵之间可以相互监控
哨兵部署原则
- 无论主从各部署一个哨兵
- 每个哨兵与其对应的节点网络相同或相近
哨兵配置
主要配置解读：
port 26379 哨兵监听的端口
daemonize yes 后台启动
protected-mode no 关闭保护模式
sentinel monitor master01 10.0.0.68 6379 2 监控的master的名字叫做master01（自定义）,地址为10.0.0.68:6379（主节点的ip与端口），行尾最后的一个2代表在sentinel集群中，多少个sentinel认为masters死了，才能真正认为该master不可用了。
sentinel auth-pass master01 000000连接密码
sentinel down-after-milliseconds master01 15000 sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒
sentinel failover-timeout master01 120000 failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。
哨兵实现的原理
哨兵启动后与主服务器建立两条连接：
- 订阅主服务器的sentinel:hello频道获取其他监控此节点的哨兵信息
- 定期向主节点发送INFO指令获取主服务器的信息
哨兵定期执行的操作：
1、每10秒向主从服务器发送INFO命令；
2、每2秒向主从服务器的sentinel:hello频道发送自己的信息；
3、每1秒向主从服务器和其他哨兵发送心跳PING；
主服务下线判断原则：
- 主观下线：当前哨兵判断节点下线；
- 客观下线：询问其他哨兵后且认为其下线的哨兵个数为
quorum参数值
如果被判定为客观下线后哨兵们会通过raft算法选举出领头哨兵负责去切换主从，选择的原则为过半原则。
主节点的选择依据：
1、通过slave-priority参数的优先级；
2、复制越完全越优先；
3、以上判断不了的话看节点ID大小，选择小的。
CLUSETER集群
集群支持几乎所有单机实例的命令，但是涉及多键的命令，比如MGET如果这些键在同一个节点上可以正常执行，但是如果不在同一个节点上就会出现问题。（这里所说的是在一个节点上操作，对于开发人员不必关心，因为有些开发语言已经提供了现成的库）
特点：
- 在Redis集群中所有节点都使用0号数据库，可以暂时理解为没有了库号的概念；
- 在Redis集群中键被分配到插槽slot中，每个集群有16384个插槽，编号从0到16383；
- 每个节点管理部分插槽，所以键是分布在不同节点上的；
- 至少3个主节点，可以没有从节点，但是实际中没有这么干的；
集群配置
1、修改配置文件
- 每个节点配置文件中添加
cluster-enabled yes - 配置
cluster-config-file node-1.conf，每个节点名字不同
执行完成后使用INFO cluster查看集群是否开启。
2、使用redis-trib.rb(Ruby语言开发的，跟我没关系)工具配置集群，命令如下：
redis-trib.rb --replicas 1 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 192.168.1.13:6379 192.168.1.14:6379 192.168.1.15:6379
解读：共6个节点，--replicas 1的意思是每个主节点1个从节点，所以计算下来就是3主3从。
执行完成后使用INFO NODES查看节点信息。
以上配置完成后，每个节点相互间会发送PING命令，来确定对方是否还好好活着。
节点添加
向新节点上使用cluster meet ip port，注意IP和PORT是集群中任何一个节点的IP和port，任何一个节点接受到之后会告知其他节点。
以上操作仅仅是加入一个新节点，至于让它作为主节点还是从节点还需下一步操作：
- 如果作为主节点，需要申请插槽（如果是这种情况一般一次性添加至少2个节点，即1主1从），使用
redis-trib.rb reshard IP:port进行重新分片，通过cluster slots查看插槽的分布情况。 - 如果作为从节点，使用
cluster replicate 主redis的ID命令
键的分配
原则：将键名的有效部分的CRC16算法计算后跟16384取余。
有效部分：
1、包含{}的键名，有效部分为花阔里面的，如键名为{student}:name有效部分为student；
2、不包含{}的键名，整个键名都是有效部分。
键和插槽的对应
之前说过，开发人员无需担心键名在哪里，因为它们使用的语言有现成的库工具会自动处理。但是如果不支持的语言呢？
这个时候要通过一个新的概念，MOVE重定向请求。
比如：主节点A和B，A节点执行：
set name hades
在B节点上再次执行时，回返回如下：
(error) MOVE 槽位号 IP:PORT
它会告诉你应该在哪里执行。
Redis-cli客户端提供了集群模式支持自动的重定向，如下：
redis-cli -c -h 127.0.0.1 -p 6379
注意：这个时候是把命令重定向发送给另一个节点了，会有请求延时。但是无需担心，redis提供了路由的功能，会把槽位和节点缓存下来，所以说慢慢会好的。
