redis集群

主从复制

主从复制原理：

• 从服务器连接主服务器，发送SYNC命令； 
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

 主从复制优点：

•  master能自动将数据同步到slave，可以进行读写分离，分担master的读压力
•  master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

 主从复制缺点：

•  不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复
•  master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

哨兵模式

　　当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

• 监控主服务器和从服务器是否正常运行。 
• 主服务器出现故障时自动将从服务器转换为主服务器。

　主客观下线

　　主观下线：每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线

　　客观下线：当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会 做出客观下线的决定

　定时监控

　　10S：每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构

通过向主节点执行info命令，获取从节点的信息，这也是为什么 Sentinel节点不需要显式配置监控从节点。当有新的从节点加入时都可以立刻感知出来，节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息

　　2S：每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息 ，同时每个Sentinel节点也会订阅该频道

发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接。Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据

　  1S：每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达；

Cluster模式

　　redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。Redis-Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
• 节点的fail是通过集群中超过半数的节点检测失效时才生效。
• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

　　使用集群，只需要将每个数据库节点的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行。集群可以使用的功能是普通单机Redis所使用的功能的一个子集，比如，Redis集群并不支持处理多个keys的命令，因为这需要在不同节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会出现无法预估的错误。Redis Cluster模式不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。

　　分片算法（hash slot）

　　1.简单哈希算法

　　假设有三台机，数据落在哪台机的算法为：

c = Hash(key) % 3

　　例如key A的哈希值为4，4%3=1，则落在第二台机。Key ABC哈希值为11，11%3=2，则落在第三台机上。利用这样的算法，假设现在数据量太大了，需要增加一台机器。A原本落在第二台上，现在根据算法4%4=0，落到了第一台机器上了，但是第一台机器上根本没有A的值。这样的算法会导致增加机器或减少机器的时候，引起大量的缓存穿透，造成雪崩。

　　2.哈希槽

　　Redis集群（Cluster）采用了哈希槽（SLOT）的这种概念。首先哈希槽其实是两个概念，第一个是哈希算法。Redis Cluster的hash算法不是简单的hash()，而是crc16算法，一种校验算法。另外一个就是槽位的概念，空间分配的规则。其实哈希槽的本质和一致性哈希算法非常相似，不同点就是对于哈希空间的定义。一致性哈希的空间是一个圆环，节点分布是基于圆环的，无法很好的控制数据分布。而Redis Cluster的槽位空间是自定义分配的，类似于Windows盘分区的概念。这种分区是可以自定义大小，自定义位置的。

　　redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot。hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。移动hash slot的成本是非常低的