深入浅出百亿请求高可用Redis(codis)分布式集群揭秘

codis的架构本身分成proxy集群+redis集群，proxy集群的高可用，可以基于zk或者l5来做故障转移，而redis集群的高可用是借助于redis开源的哨兵集群来实现，那边codis作为非redis组件，需要解决的一个问题就是如何集成redis哨兵集群。本节将该问题分成三部分，介绍redis哨兵集群如何保证redis高可用，codisproxy如何感知redis哨兵集群的故障转移动作，redis集群如何降低“脑裂”的发生概率。

5.2.1 哨兵集群如何保证redis高可用

Sentinel(哨岗，哨兵)是Redis的高可用解决方案：由一个或多个Sentinel实例组成的Sentinel系统，可以监视任意多个主服务器，以及这些主服务器属下的所有的从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由主服务器代替已下线的主服务器继续处理命令请求。

通常来说要达到服务的高可用的效果需要做2个事情：故障探测与故障转移(即选主并做主从切换)。

5.2.2 codis如何感知哨兵集群的故障转移动作

codis的架构本身分成proxy集群+redis集群，redis集群的高可用是由哨兵集群来保证的，那么proxy是如何感知redis主机故障，然后切换新主保证服务高可用的呢?

如上图所示，proxy本身会监听sentinle集群的+switch-master事件，该事件发出，意味着redis集群主机出现问题，sentinel集群开始进行选举并切换主机，proxy监听了sentinel的主从切换事件，收到主从切换事件之后，proxy会做一个动作，就是把所有sentinel上的集群所感知的当前认为的主机拉取出来，选取过半sentinel认为的主机当作目前的集群主机。

讲到这里，大家可能会忽略一个问题，就是配置存储，配置中心的存储还是旧的主机，一旦proxy重起，那拉取的依旧是故障的主机，其实dashboard和proxy也做了一样的事情，收到主从切换事件之后，就会将新主持久化到storage中(目前为zk)

5.2.3 脑裂处理

脑裂(split-brain)集群的脑裂通常是发生在集群中部分节点之间不可达而引起的。如下述情况发生时，不同分裂的小集群会自主的选择出master节点，造成原本的集群会同时存在多个master节点。，结果会导致系统混乱，数据损坏。

在这个问题上，这里simotang同学已经讲解的非常完善了，大规模codis集群的治理与实践，这里简单说一下，由于redis集群不能单纯的依赖过半选举的模式，因为redismaster自身没有做检测自身健康状态而降级的动作，所以我们需要一种master健康状态辅助判断降级的方式。具体实现为

1)降级双主出现的概率，让Quorums判断更加严格，让主机下线判断时间更加严格，我们部署了5台sentinel机器覆盖各大运营商IDC，只有4台主观认为主机下线的时候才做下线。

2)被隔离的master降级，基于共享资源判断的方式，redis服务器上agent会定时持续检测zk是否通常，若连接不上，则向redis发送降级指令，不可读写，牺牲可用性，保证一致性。

六、codis水平扩容细节&迁移异常处理

由于codis是针对redis分布式的解决方案，必然会面临着redis单点容量不足的情况下水平扩容的问题，本节主要针对codis水平扩容与迁移异常的细节做一下说明，大家先带着两个问题来看，问题一，迁移过程中，正在迁移的key的读写请求怎么处理，问题二，迁移过程中的异常(例如失败，超时)怎么处理。

6.1 Codis扩容迁移细节

【图】迁移流程

影响面：

一阶段期间的影响：通知到通知成功结束期间，proxy读写请求阻塞，不丢失，延时增高(时间极短，并行通知，仅仅修改状态，使proxy中slot状态达到一致)

迁移过程：可读，正在迁移批次的不可写，迁移完成的批次涉及到两次网络io

如上图所示，其实redis平滑迁移过程，主要是实现了3个点，迁移准备，迁移动作，迁移性能保证。

迁移准备

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!