redis集群

redis集群：
	主从模式：
		缺点：
			主节点出现故障后，需要手动将一个从节点晋升为主节点，并修改其它从节点的主从关系，同时需要修改应用方主节点地址的配置，无法实现redis的高可用。
			主节点的存储容量、写性能受到单机的限制。

		相比单机的优点：
			主节点故障后，可手动将从节点设置为主节点，保证数据尽量不丢失。
			从节点可以分担主节点读的压力。
				eg：客户端直接连接从节点来读取实时性不太敏感的数据。注意：若从节点晋升为主节点，则客户端需要修改从节点的地址。
		
					
		
	哨兵模式：
		概念：
			Redis Sentinel中包含若干个Sentinel节点和Redis数据节点(主节点和从节点)，
			每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现某个节点不可达时，会对节点做下线标识。
			如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，
			它们会选举出一个Sentinel节点(leader)来完成自动故障转移的工作，同时会将这个变化实时通知给客户端，整个过程都是自动完成的。

		缺点：主节点的存储容量、写性能受到单机的限制。
			
		优点：哨兵自动完成故障发现和故障转移并通知应用方，从而实现redis的高可用。
			故障发现：哨兵监控主数据库和从数据库是否运行正常
			故障转移：哨兵在主节点出现故障后自动将从节点库转化为主数据库。
			通知应用方：哨兵将故障转移的结果通知给应用方。
			说明：客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

		客户端：
			指定Sentinel节点的集合、主节点名称masterName即可连接上redis sentinel。
			为每一个Sentinel节点单独启动一个线程，利用Redis的发布订阅功能，每个线程订阅Sentinel节点上切换master的相关频道。
			
		原理：
			三个定时任务：
				每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
				每隔2秒，每个Sentinel节点会向Redis数据节点和其它sentinel节点发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息
				每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。
				
			主观下线：
				sentinel节点通过心跳发现某个节点不可达，则判断该节点离线。
				
			客观下线：
				当Sentinel主观下线的节点是主节点时，该Sentinel节点会向其它Sentinel节点询问对主节点的判断，若max(quorum, num(sentinels)/2+1)个数的Sentinel节点认为主节点离线，则该Sentinel节点会做出客观下线的决定。
				说明：从节点、Sentinel节点在主观下线后，没有后续的故障转移操作。
			领导者选举：
				当某个sentinel节点做出客观下线的决定后，接着需要从sentinel集合中选出一个Sentinel节点作为领导者进行故障转移的工作。
				说明：选举的过程非常快，基本上谁先完成客观下线，谁就是领导者。
				
			故障转移：
				选取一个从节点(选取规则：健康的+优先级最高的+数据复制最完整的+runid最小的)作为主节点。
			
		说明：
			一套Sentinel集合可以监控多个主从结构。
		
		版本：
			支持版本：2.8及以上。
			使用版本：3.2.8
			
		两机房三哨兵部署：
			部署方案：master部署在A机房，slave部署在B机房，多数哨兵部署在B机房。
			优点：实现了多机房的高可用性，当一个机房故障时，仍然可以自动完成failover，并提供正常的服务。
			说明：
				当A机房故障时，多数哨兵仍然可以正常工作，故failover操作会成功，最后在B机房中选出master。注意：A机房恢复后，手动将A机房的机器设置为master，恢复到初始状态。
				当B机房故障时，因master没有受影响，故可以正常工作。
			举例：master部署在A机房，2个slave部署在B机房，部署3个哨兵，A机房部署1个哨兵，B机房部署2个哨兵。
		 
		
	集群模式：
		概念：Redis Cluster
		
		优点：集群容量伸缩、集群高可用。
		
		缺点：
			key批量操作支持有限
			不支持多数据库，只能使用db0
			key事务操作有限
			
		原理：
			集群伸缩：
				当加入1个节点来对集群进行扩容时，通过相关命令把一部分槽和数据迁移给新节点。
				
				Redis cluster采用虚拟槽分区的数据分区方案：
					redis cluster接收任何键相关命令时首先计算键对应的槽，再根据槽找出所对应的节点：
						若节点是自身，则处理键命令；
						若节点不是自身，则回复MOVED重定向错误，通知客户端请求正确的节点，这个过程称为MOVED重定向。
					槽的范围：
						虚拟槽的范围是0~16383
					计算槽：
						根据键计算出散列值，再取对16383的余数，使每个键都可以映射到0~16383槽范围内。
					槽节点查找：
						集群内通过消息交换每个节点都会知道所有节点的槽信息		
					优点：
						解耦数据和节点之间的关系，降低了节点扩容和收缩的难度。
						支持节点、槽、键之间的映射查询。
				
			高可用：
				主观下线：
					集群中任意一个节点通过心跳发现某个节点不可达，则判断该节点离线。
					
				客观下线：
					当半数以上持有槽的主节点认为该节点已经离线，则触发客观下线流程。
					说明：
						只有持有槽的主节点才负责读写请求和集群槽等关键信息维护，故只有持有槽的主节点参与故障发现的决策。
						参与投票的主节点最少为3个，且每个主节点最少有一个从节点()，故redis cluster最少需要6个节点才能保证集群的高可用性。
				领导者选举：
					故障节点变为客观下线后，若下线节点是持有槽的主节点，则需要从持有槽的主节点中选出一个节点作为领导者进行故障转移的工作。
					
				故障转移：
					选取一个从节点(选取规则：健康的+优先级最高的+数据复制最完整的+runid最小的)作为主节点。
			

		集群客户端：
			普通客户端：
				接收到MOVED重定向信息后再次发起请求。
			智能客户端：
				在内部维护slot与node的映射关系，本地就可实现键到节点的查找，从而保证IO效率的最大化，
				接收到MOVED重定向响应后，客户端更新slot与node的映射关系。