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

如下图所示：该部分主要涉及到codis的路由细节，主要涉及到如何将一个key映射到具体的物理结点。

【图】路由映射细节

如上图所示：该部分主要涉及到codis的路由细节。

| 相关词汇说明

slot：分片信息，在redis当中仅仅表示一个数字，代表分片索引。每个分片会归属于具体的redis实例。

group:主要是虚拟结点，由多台redis机器组成，形成一主多从的模式，是逻辑意义上的结点。

为了帮助大家对proxy路由映射的细节有一个更深入的理解，我整理了几个常见的路由映射的相关问题来帮忙大家理解。

问题一：proxy是如何把请求映射到具体的redis实例中?

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语言这种从语言层面天然支持协程的语言来实现的。

（编辑：网站开发网_马鞍山站长网）

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