如何破解Redis集群难题？
只有了解的集群的故障转移的机制以及问题，才能在我们实际的业务中立于一个不败之地。
///
Redis 集群失效检测
Redis 集群失效检测是用来识别出大多数节点何时无法访问某一个主节点或从节点。
当这个事件发生时，就提升一个从节点来做主节点；若如果无法提升从节点来做主节点的话，那么整个集群就置为错误状态并停止接收客户端的查询。
每个节点都有一份跟其他已知节点相关的标识列表。其中有两个标识是用于失效检测，分别是 PFAIL 和 FAIL。
失效检测标识
PFAIL 表示可能失效（Possible failure），这是一个非公认的（non acknowledged）失效类型。FAIL 表示一个节点已经失效，而且这个情况已经被大多数主节点在某段固定时间内确认过的了。
PFAIL：当在集群中有一个节点超过 NODE_TIMEOUT 的时间后仍然无法访问某个节点，那么它会用PFAIL来标识这个不可达的节点。无论节点是什么类型，主节点和从节点都可以标识其他不可达的节点为PFAIL。
FAIL：如何让一个节点真正的被认为失效了呢，那么需要让PFAIL标识升级到FAIL状态。我们集群中每个几点都会发送gossip的消息，这个消息中含有一些随机的已知节点的状态。最终每个节点都会受到一份其他节点的节点标识。
节点的选举和提升
从节点的选举和提升都是由从节点处理的，主节点会投票要提升哪个从节点。一个从节点的选举是在主节点被至少一个具有成为主节点必备条件的从节点标记为 FAIL 的状态的时候发生的。
当以下条件满足时，一个从节点可以发起选举：该从节点的主节点处于 FAIL 状态；这个主节点负责的哈希槽数目不为零。
从节点和主节点之间的重复连接（replication link）断线不超过一段给定的时间，这是为了确保从节点的数据是可靠的。
节点投票
一个从节点想要被推选出来，那么第一步应该是提高它的 currentEpoch 计数，并且向主节点们请求投票。
从节点通过广播一个 FAILOVER_AUTH_REQUEST 数据包给集群里的每个主节点来请求选票。然后等待回复（最多等 NODE_TIMEOUT 这么长时间）。
一旦一个主节点给这个从节点投票，会回复一个 FAILOVER_AUTH_ACK，并且在 NODE_TIMEOUT * 2 这段时间内不能再给同个主节点的其他从节点投票。在这段时间内它完全不能回复其他授权请求。
一个节点选举
从节点会忽视所有带有的时期（epoch）参数比 currentEpoch 小的回应（ACKs），这样能避免把之前的投票的算为当前的合理投票。
一旦某个从节点收到了大多数主节点的回应，那么它就赢得了选举。否则，如果无法在 NODE_TIMEOUT 时间内访问到大多数主节点，那么当前选举会被中断并在 NODE_TIMEOUT * 4 这段时间后由另一个从节点尝试发起选举。
Redis集群没有直接使用从节点进行领导者选举，主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点，将导致从节点资源浪费。使用集群内所有持有槽的主节点进行领导者选举，即使只有一个从节点也可以完成选举过程。
替换主节点操作
当从节点收集到N/2+1个持有槽的主节点投票时，从节点可以执行替换主节点操作，例如集群内有5个持有槽的主节点，主节点b故障后还有4个，当其中一个从节点收集到3张投票时代表获得了足够的选票可以进行替换主节点操作。
故障主节点也算在投票数内，假设集群内节点规模是3主3从，其中有2个主节点部署在一台机器上，当这台机器宕机时，由于从节点无法收集到3/2+1个主节点选票将导致故障转移失败。这个问题也适用于故障发现环节。因此部署集群时所有主节点最少需要部署在3台物理机上才能避免单点问题。
当从节点收集到足够的票数之后，触发替换主节点的操作。
集群完整性
为了保证集群完整性，默认情况下当集群16384个槽任何一个没有指派到节点时整个集群不可用。执行任何键命令返回（error）CLUSTERDOWNHash slot not served错误。
这是对集群完整性的一种保护措施，保证所有的槽都指派给在线的节点。但是当持有槽的主节点下线时，从故障发现到自动完成转移期间整个集群是不可用状态，对于大多数业务无法容忍这种情况，因此建议将参数cluster-require-full-coverage配置为no，当主节点故障时只影响它负责槽的相关命令执行，不会影响其他主节点的可用性。
四种解决方案
数据分布在不同的节点之间，那么不同的节点之间的数据量和请求量肯定也是不一样的，这种情况下，会导致我们集群节点的负载不一样，增加我们维护的困难。那么首先我们先去了解一下为什么会有这种情况的发生。
第一种情况：当我们进行扩容或者缩容时由于手动的数据槽迁移，导致的节点和数据槽映射关系发生改变，从而节点上的数据槽不平均（集群创建时，根据算法是平均的），如果数据槽的数量发生了较大的改变，那么数据槽较多的节点的压力就会比较大，反之就会有节点不能有效的承担负载。
解决方案：我们可以通过redis-trib.rb info 192.168.188.191:8002来查看我们的槽位和节点的分布情况，如果出现差异较大时可以手动迁移数据槽或者使用 redis-trib.rb rebalance来进行重新平均的操作。
第二种情况：我们在做数据写入的时候，会有根据键值的情况进行计算，来分配槽位。那么如果一个槽位的数据量较大，而其他槽上的数据量较少，也会出现这样的问题，都会导致读和写的负载不均衡。
解决方案：在使用的过程中，按照默认的CRC16哈希函数的算法理论上来比较平均，如果使用较多的hash_tag时会产生数据槽内键值不平均的情况，这个就比较简单找出所有使用hash_tag的键值，重新分配或者减少使用hash_tag就可以了。
第三种情况：就是我们配置的内存或者说我们系统所允许使用的内存配置不一样，也会出现这样的情况。
解决方案： 统一redis以及系统内核参数配置。
第四种情况：就是个别的key的数据比较大，也会导致某些槽或者节点出现负载不平均的情况。
解决方案：通过业务上了解，降低或者拆分这种比较大的数据集合，这样的话，可以有效避免这个问题。
柯普瑞企业IT学院
柯普瑞企业IT学院创始于2002年，隶属于南京柯普瑞信息技术有限公司。柯普瑞专注于推动政府、企业信息化建设与发展，为客户提供包括：IT培训、IT运维服务、信息安全服务、商业智能服务、OA应用服务及人力资源外包等专业化服务。十多年来已经服务了超过3000家客户，获得了广泛的客户认可！
柯普瑞企业IT学院长期致力于为政府及企业客户提供专业化IT高端技术培训解决方案，帮助客户进行持续性IT人才梯队建设和培养。公司拥有一支由业内资深专家、厂商资深认证讲师组成的百人专家型职业讲师团队，提供包括网络技术、主机技术、软件开发技术、大型数据库技术、中间件技术、虚拟化技术、信息安全技术、云计算及大数据、IT管理、IT应用等不同专业方向百余门IT技术及管理课程。
基于客户日趋层次化、多元化的IT业务需求，柯普瑞企业IT学院从IT系统架构、满足核心业务应用角度出发，通过专业化沟通、咨询及评估，设计出合理有效的专业培训实施方案，强调课程的针对性、实用性和高效性，通过IT专家讲师团队提供优质高效的培训服务，帮助客户有效提升员工专业技术能力和工作效率，降低企业运营成本。
企业使命：
为员工创造价值，为客户创造价值，为社会创造价值，为推动全社会进步而努力！
企业愿景：
成为中国一流的企业IT人才培养解决方案提供商！
南京校区：南京市中山东路300号
长发中心A栋23楼
杭州校区：杭州市文晖路46号
现代置业大厦西楼10层
学院网址：www.china-esp.com
长
按
关
注