redis高可用实践之FAILOVER

服务的可用性不仅仅是指服务健康运行的时间，还包括出现故障以后的恢复速度。保证一个服务的高可用，基本可以从 软件质量 故障预防 故障恢复三方面着手。对于redis，软件的质量本身有很大的保障，因此对于线上大规模的redis集群运维管理，基本上可以从故障预防和故障恢复两方面着。虽然redis cluster本身具有自动主从容灾的高可用能力，但是某些场景cluster依然无法很好地处理。本文将结合CLUSTER FAILOVER 集群管理命令详细介绍如何进一步提升redis集群的可用性。

首先对CLUSTER FAILOVER命令做个介绍:

CLUSTER FAILOVER处理流程

1. 通知master停止处理来自客户端的请求
2. master响应当前最大的replication offset
3. 客户端等待复制复制同步完成直到replication offset
4. 提升epoch并获取半数leader的选举认可
5. 更新configuration并解除客户端的阻塞请求，返回重定向到新的master

该操作用于正常的主从切换，但是如果master节点宕机了无法响应failover请求，那么failover将会失败，为了处理master宕机的情况，可以添加FORCE 选项。

CLUSTER FAILOVER FORCE: 添加FORCE选项时，failover流程直接从上述的第4步开始，也即跳过了和旧master通信协商复制数据的过程，当master宕机时，force选项可以快速进行人工主从切换。但是该过程仍然需要获得半数master的统=同意才能当选为新主。当出现半数master节点异常时，该流程无法进行主从切换。

CLUSTER FAILOVER TAKEOVER: 为了处理半数master节点异常的场景，可以添加****TAKEOVER 选项。通过TAKEOVER 选项，可以无需获得半数master的认同，而是直接更新状态为master并向所有可达的节点发送最新配置epoch。****

接下来将结合场景介绍如何通过FAILOVER 提升集群可用性

主从节点均衡漂移切换，负载均衡

防患以未然，当机器负载过高或者出现异常故障时，需要将部署在该机器的redis实例迁移出,迁移流程包含:

1. 在新的机器部署一个slave实例并同步数据
2. 同步完数据以后将旧的实例下线。

如果旧机器有实例处于master，则需要先将role改外slave，然后在进行迁移，此时可以通过对slave节点发送cluster failover，将节点改为slave以后在进行删除。

FORCE: 主节点宕机时快速选主

最理想的情况是出现故障之前提前解决处理，但是这毕竟只是理想。当节点宕机或者负载过高导致无法响应时，可能出现FAILOVER失败的情况，此时则可以通过添加FORCE选项进行强制主从切换，将健康的slave节点提升为master从而快速恢复服务。

TAKEOVER: 半数master故障时，强制更新快速止损恢复服务。

虽然在线上环境的部署上，redis的master节点会做到尽可能分散，但是在某些场景写，还是可能出现半数master节点故障的情况:

1. 测试环境机器上，部分机器宕机可能导致超过半数master异常，此时redis集群无法自动恢复，虽然是测试环境，但是故障快速修复依然同样重要，否则会验证影响研发测试进度。
2. 多活部署场景，多活场景下，通常可以将主节点部署在一个机房，从节点部署在另外一个机房提供读或者容灾。当机房出现故障时，此时则可以通过添加takeover选项将从机房的节点提升为主，快速恢复集群写能力。

总结

虽然redis cluster本身提供了高可用的能力，但是在某些场景下依然需要人为介入进行处理，本文介绍了FAILOVER的几种应用实践场景，通过将该操作和option集成到自动运维平台，进一步提升了redis的可用性。