详解Redis集群原理核心内容.docxVIP

详解Redis集群原理核心内容 一个系统建立集群次要需要处理两个问题：数据同步问题和集群容错问题。 Naive方案 一个简约粗暴的方案是部署多台一模一样的Redis服务，再用负载均衡来分摊压力以及监控服务形态。这种方案的优势在于容错简约，只需有一台存活，整个集群就仍旧可用。但是它的问题在于保证这些Redis服务的数据全都时，会导致大量数据同步操作，反而影响功能和稳定性。 Redis集群方案 Redis集群方案基于分而治之的思想。Redis中数据都是以Key-Value方式存储的，而不同Key的数据之间是相互独立的。因而可以将Key依据某种规章划分成多个分区，将不同分区的数据存放在不同的节点上。这个方案类似数据结构中哈希表的结构。在Redis集群的实现中，使用哈希算法（公式是CRC16(Key) mod 16383）将Key映射到0~16383范围的整数。这样每个整数对应存储了若干个Key-Value数据，这样一个整数对应的笼统存储称为一个槽（slot）。每个Redis Cluster的节点——精确?????讲是master节点——担任肯定范围的槽，全部节点组成的集群掩盖了0~16383整个范围的槽。 听说任何计算机问题都可以通过添加一个两头层来处理。槽的概念也是这么一层。它介于数据和节点之间，简化了扩容和收缩操作的难度。数据和槽的映射关系由固定算法完成，不需要维护，节点只需维护本身和槽的映射关系。 Slave 上面的方案只是处理了功能扩展的问题，集群的毛病容错力量并没有提升。提高容错力量的方法一般为使用某种备份/冗余手段。担任肯定数量的槽的节点被称为master节点。为了添加集群稳定性，每个master节点可以配置若干个备份节点——称为slave节点。Slave节点一般作为冷备份保存master节点的数据，在master节点宕机时替换master节点。在一些数据访问压力比较大的情况下，slave节点也可以供应读取数据的功能，不过slave节点的数据实时性会略差一下。而写数据的操作则只能通过master节点进行。 恳求重定向 当Redis节点接收到对某个key的命令时，假如这个key对应的槽不在本人的担任范围内，则前往MOVED重定向错误，通知客户端到正确的节点去访问数据。 假如频繁消灭重定向错误，势必会影响访问的功能。由于从key映射到槽的算法是固定公开的，客户端可以在内部维护槽到节点的映射关系，访问数据时可以本人通过key计算出槽，然后找到正确的节点，削减重定向错误。目前大部分开发言语的Redis客户端都会实现这个策略。这个地址https://redis.io/clients可以查看主流言语的Redis客户端。 节点通信 虽然不同节点存储的数据相互独立，这些节点仍旧需要相互通信以同步节点形态信息。Redis集群接受P2P的Gossip协议，节点之间不断地通信交换信息，最终全部节点的形态都会达成全都。常用的Gossip消息有下面几种： ping消息：每个节点不断地向其他节点发起ping消息，用于检测节点能否在线和交换节点形态信息。 pong消息：收到ping、meet消息时的响应消息。 meet消息：新节点加入消息。 fail消息：节点下线消息。 forget消息：遗忘节点消息，使一个节点下线。这个命令必需在60秒内在全部节点执行，否则超过60秒后该节点重新参与消息交换。实践中不建议直接使用forget命令来操作节点下线。 节点下线 当某个节点消灭问题时，需要肯定的传播时间让多数master节点认为该节点的确不行用，才能标记标记该节点真正下线。Redis集群的节点下线包括两个环节：客观下线（pfail）和客观下线（fail）。 客观下线：当节点A在cluster-node-timeout时间内和节点B通信（ping-pong消息）一直失败，则节点A认为节点B不行用，标记为客观下线，并将形态消息传播给其他节点。 客观下线：当一个节点被集群内多数master节点标记为客观下线后，则触发客观下线流程，标记该节点真正下线。 毛病恢复 一个持有槽的master节点客观下线后，集群会从slave节点中选出一个提升为master节点来替换它。Redis集群使用选举-投票的算法来选择slave节点。一个slave节点必需获得包括毛病的master节点在内的多数master节点的投票后才能被提升为master节点。假设集群规模为3主3从，则必需至少有2个主节点存活才能执行毛病恢复。假如部署时将2个主节点部署到同一台服务器上，则该服务器不幸宕机后集群无法执行毛病恢复。 默认情况下，Redis集群假如有master节点不行用，即有一些槽没有担任的节点，则整个集群不行用。也就是说当一个master节点毛病，到毛病恢复的这段时间，整个集群都处于不行用的