redis集群的高可用性实现

当主从的redis性能和容量满足不了项目的需求时，一般会采用集群方案。而原生的集群方案是一个比较好的选择。本文主要是讨论如何保证集群版高可用。高可用分为选择最佳的机器、修复节点故障、升级或者修复软件故障、让数据落地保存这几个方面。

分配算法

当一个集群中超过一半的master节点在同一个机器上，而这个机器宕机后，它会导致整个集群不可用，为了规避这个问题，分配时应避免将同一个集群一半的主节点分配到同一个机器，同时为了规避主从切换后有一半的主节点在同一机器上的可能性，那就需要限制机器上集群的节点不超过主节点数的一半。由于每个节点故障后，都会对集群造成影响。为了减少这个影响，分配时，可以在保证集群的稳定性的同时，将节点尽量分配到同一台机器上。为了方便计算，这里引入了亲和力的概念，其计算公式如下：x表示分配后每个机器上的节点数，nodes 表示分片数(主节点个数)。

Affinity_socre(x)=x*2/nodes (x<nodes/2) Affinity_socre (x)=-Max (x>=nodes/2)

其中第一条表示在不超过一半的情况，节点越多越好，第二条不能超过一半的节点分配到这个机器上。

比如3主3从：总共有6个节点：

第1个节点，1<3/2，因此Affinity_socre(1)=1*2/3

第2个节点，2>3/2，因此Affinity_socre(2)=-Max

可以看出每个机器上面只能分配1个节点，完全分配完所有的节点就需要6台机器。

除了考虑亲和力得分外，在实际分配中还需要考虑内存、网络、CPU等使用率等，当多个因素引入时，就需要为每个因素的加上权重。我们假如分配的权重为（0.1,0.3,0.5,0.1）。分配计算的总得分公式变成如下： Score = free_cpu*0.1+free_net*0.3+ Affinity_socre (x)*0.5+free_mem*0.1

其中：free_cpu表示现在机器可用的cpu比率。free_net表示可用的网络流量，free_mem表示可用的内存比较。

对于主节点和从节点分配的时候比例可以使用不同权重。其中在计算使用率时，不能只选择当时的情况，需要考虑历史的使用率。因此我们可以加入平滑因子，比如计算可用的cpu时，其计算公式如下： free_cpu[1]= free_cpu[1]（i=1）

free_cpu[i] = ( ALPHA * free_cpu[i-1] ) + ((1-ALPHA) * free_cpu [i]) （i>1）

其中ALPHA取7/8。free_cpu就是当时可用的使用比例。

分配算法

节点故障处理。

当机器出现宕机时，在该机器的节点也随之出现问题，节点分为两种，主节点和从节点，如果是从节点，那对集群无明显影响，只需要我们将这个节点forget掉，然后补从新的集群节点。而如果该节点是主节点，会在cluster-node-timeout后，将这个主节点判断为fail状态，从节点发现主为fail后，会向集群发起投票来选取主节点。当主节点选取成功后，那我们再补充相应的从节点即可。

节点故障处理

实例整体升级功能。

无论是redis-server还是redis-server的接入代理proxy程序需要升级时，都需要保证对业务存不存在影响，针对Proxy和redis-server升级流程不同。

对redis-server升级时，首先替换从节点，然后再替换主节点。替换从节点时，首先分配一个节点，然后将这个节点加入到集群中，加入成功后，再forget老的从节点。最后删除之前老的节点。

所有的从节点替换完后，需要继续升级主节点。升级主节点的流程需要先新建一个从节点，同样将这个节点加入到集群中。等待加入的从节点同步好后，就可以调用failover命令，将主节点标志为fail，这个时候会有最多10s的时间暂时停止处理请求，然后在主从数据同步完后会发起从投票选取新的主节点，完成主节点的选举，就可以将需要替换的redis-server下线。所有的主节点升级完后，整个redis-server集群就升级完成了。

Proxy升级相对简单，先创建新的proxy，然后将它的vpc映射到新的proxy上面，而老的proxy会通过延迟一定的时间后关闭。

在升级proxy中。如果用户是短连接，那对用户不存在任何影响。而之前的旧连接在延迟删除的时间如果未断开，则会强制断开连接。

实例整体升级

定时备份。

除上面的几个方面保证可用性以外，数据的冷备也相当重要，当多台机器同时故障，就需要从冷备的数据中还原集群的数据。集群版本备份需要对每个节点进行备份，在备份的时候为了不影响业务，一般建议在备机上面备份。每次发起备份，可以通过它的info信息来进行判断是否已经备份成功。在备份前，查看redis的rdb_last_save_time,然后轮训检查rdb_last_bgsave_status和rdb_last_save_time来核对是否rdb生成成功。也可以直接使用LASTSAVE来查看是否dump成功。在rdb已经dump到磁盘后，还需要将rdb文件上传到对象存储中。