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

Codis基于crc32的算法%1024得到对应的slot，slot就是所谓的逻辑分片，同时codis会将对应的逻辑分片映射到对应的虚拟结点上，每个虚拟结点是由1主多从的物理redis结点组成。至于为啥会用crc32，这个具体也没有细究，作者也是借鉴于rediscluster中的实现引入的。通过引入逻辑存储结点group，这样即使底层的主机机器实例变更，也不映射上层的映射数据，对上层映射透明，便于分片的管理。

问题二，proxy是如何做到读写分离

如上图所示，key映射到具体的虚拟结点时，能够感知到虚拟结点对应的主与备机实例，此时redisproxy层面能够识别到具体的redis命令得到对应的命令是读与写，再根据集群的配置是否支持读写分离的特性，如配置的是支持，则随机路由到主与从机实例，如配置的是不支持，则路由到主机补全。

问题三，proxy目前支持哪些命令，是否支持批量命令，如何保证原子性

命令支持链接

命令支持部分：Prxoy支持的命令分为三种：不支持命令，半支持命令，支持命令，除了上表所示命令外，其他命令proxy均是支持的，其中不支持命令部分主要是因为这些命令参数中没有key,因此无法识别路由信息，不知道具体路由到哪台实例上，而半支持命令部分通常是会操作多个key,codis基于一种简单实现，以第一个key的路由为准，因此需要业务方自己来保持多个key路由到同一个slot,当然业务也是可以不保证，具体后果业务来承担，是一种弱校验的模式，而公司级产品ckv+对于多key操作是强校验，如果多key不在同一slot上，则以错误的形式返回。

多key操作&原子性部分：Redis本身对于多key的一些操作例如mset等命令是原子性的，而在分布式操作下，多key会分布到多个redis实例当中，涉及到分布式事务，所以在codis当中进行了简化处理，多key操作拆成多个单key命令操作，所以codis当中的mset多key操作不具备原子性的语义。

问题四，如何保证多个key在一个slot当中

有些场景下，我们希望使用到lua或者一些半支持命令来保证我们操作的原子性，因此我们需要在业务层面来去保证多key在一个slot当中，codis采用了和rediscluster一样的模式，基于hashtag，例如我想让七天的主播榜单都中路由在同一个slot的话，{anchor_rank}day1,{anchor_rank}day2,{anchor_rank}day3，即可支持，对就是采用大括号的模式，codis会识别大括号，只会取大括号中的字符串进行hash操作。

4.2.2Proxy请求处理细节

如下图所示：该部分主要涉及到proxy的处理细节，涉及到如何接受一个请求到响应回包的过程。

【图】Proxy请求处理细节

如上图所示：该部分主要涉及到proxy的处理细节。

Codisproxy主要基于go语言这种从语言层面天然支持协程的语言来实现的。

1)proxy接收客户端的连接之后，新建一个session,同时启动session中reader与writer两个协程，reader主要用于接收客户端请求数据并解析，对多key的场景下进行命令的拆分，然后将请求通过router进行分发到具体的redis实例，并将redis处理的数据结果写到通道到中，writer从通道中接收对应的结果，将写回给客户端。

2)Router层主要是通过crc命令得到key对应的路由信息，从源码可以看到hashtag的特性，codis其实也是支持的。

至此，proxy相关的路由映射与请求处理细节已经结束，整体下来是不是很简单。

五、数据可靠性&高可用&容灾&故障转移&脑裂处理

作为存储层，数据可靠性与服务高可用是稳定性的核心指标，直接影响到上层核心服务的稳定性，本节将主要针对这两个指标来做一下阐述。

5.1 数据可靠性

作为codis的实现来讲，数据高可靠主要是redis本身的能力，通常存储层的数据高可靠，主要是单机数据高可靠+远程数据热备+定期冷备归档实现的。

单机数据高可靠主要是借助于redis本身的持久化能力，rdb模式(定期dum)与aof模式(流水日志)，这块可以参考前文所示的2本书来了解，其中aof模式的安全性更高，目前我们线上也是将aof开关打开，在文末也会详细描述一下。

远程数据热备主要是借助于redis自身具备主从同步的特性，全量同步与增量同步的实现，让redis具体远程热备的能力。

（编辑：PHP编程网 - 黄冈站长网）

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