深入浅出百亿请求高可用Redis(codis)分布式集群揭秘-编程学习网

摘要：作为noSql中的kv数据库的王者，redis以其高性能，低时延，丰富的数据结构备受开发者青睐，但是由于redis在水平伸缩性上受限，如何做到能够水平扩容，同时对业务无侵入性是很多使用redis的开发人员都会面临的问题，而redis分布式解决方案的一个开源产品【codis】较好的弥补了这一弱势，本文主要讲解codis是如何做到对业务无感知，平滑迁移，迁移性能高，迁移异常处理，高可用以及常见的redis的避坑指南，虽然codis目前随着公司的nosql产品越来越成熟，生命周期也即将结束，不过鉴于还有很多同学对codis的原理比较感兴趣，于是将以前的分享的内容重新整理，当然codis在公司外应用目前依旧还是相对比较广泛。

一、背景

二、Redis相关基础概览

2.1Redis简介

2.2Redis的特点

2.3Redis应用场景

三、Redis分布式解决方案公司内外比较

四、Codis的架构设计

4.1 Codis整体的架构设计

4.２Codisproxy的架构设计实现

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

5.1 数据可靠性

5.2 高可用&容灾&故障转移

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

6.1 Codis扩容迁移细节

6.2 迁移异常处理

七、Codis相关数据

八、运维手册及避坑指南

九、参考资料

一、背景

随着直播元年开启，越来越多的直播产品如春笋般出现，在拉动营收的过程中，产品竭尽全力思考着各种活动来刺激用户的消费欲望，而这类活动的基础形式就是榜单，在2016年我们基于cmem及扫描流水表的方式来实现榜单排名，2017开始，我们对原有系统进行重构，使用redis作为我们的榜单基础存储，在重构的过程中接到调研redis分布式解决方案的任务之后，比对业内各种开源产品，最后定下Codis，并对其中细节做了一些研究，期间在与Codis作者交流的过程中，有幸知道增值产品部的simotang已经在部门引入codis近2年时间，遂加入到codis的运维工作中，目前在部门内部署运维codis集群15套,2T容量,总日访问量百亿+.支撑了互动视频产品部基础存储，运营活动，榜单类业务2年多,共计100多个活动，榜单上千个。同时在这里非常感谢codis作者spinlock在接入codis过程中给予的指导与帮助。见spinlock github 与 codis地址

二、Redis相关基础概览

2.1 Redis简介

redis是一个基于内存同时具备数据持久化能力的高性能，低时延的KV数据库，value的数据结构可以是string,hash表，list(列表)，set(集合)，sortedset(有序集合)。

Redis(RemoteDictionary Server)

Redis is anopen source (BSD licensed), in-memory data structure store, used as adatabase, cache and message broker. It supports data structures suchas strings, hashes, lists, sets, sorted sets with rangequeries，Practice: http://try.redis.io/

2.2 Redis的特点

1. 单线程异步架构（单线程,收包，发包，解析，执行，多路io复用接收文件事件）

2. k-v结构，value支持丰富的数据结构（string,hash,list,set,sortset）

3. 高性能，低时延，基于内存操作，Get/Set10w+，高性能，基于RDB、AOF落地保证数据可靠性

4. 丰富的特性，可用于缓存，消息队列，TTL过期

5. 支持事务，操作是原子性，要么全部提交，要么全部不提交。

2.3 Redis应用场景

string	计数器，用户信息(id)映射，唯一性（例如用户资格判断），bitmap
hash	常见场景：存储对象的属性信息（用户资料）
list	常见场景：评论存储，消息队列
set	常见场景：资格判断（例如用户奖励领取判断），数据去重等
sorted set	常见场景：排行榜，延时队列
其他	分布式锁设计推荐2篇文章：基于Redis的分布式锁到底安全吗（上） http://zhangtielei.com/posts/blog-redlock-reasoning.html 基于Redis的分布式锁到底安全吗（下） http://zhangtielei.com/posts/blog-redlock-reasoning-part2.html

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

【图codis架构图】

如上图所示，codis整体属于二层架构，proxy+存储，相对于ckv+无proxy的设计来说整体设计会相对简单，同时对于客户端连接数据逐渐增大的情况下，也不用去做数据层的副本扩容，而只需要做proxy层的扩容，从这一点上看，成本会低一些，但是对于连接数不大的情况下，还需要单独去部署proxy，从这一点上看，成本会高一些。

其中，开源的codisproxy的服务的注册发现是通过zk来实现，目前部门是基于l5来做.

从整体的架构设计图来看，codis整体的架构比较清晰，其中codisproxy是分布式解决方案设计中最核心的部分，存储路由，分片迁移均与codisproxy分不开，这块我们来看一下codisproxy的设计实现。

codisproxy的架构实现分成2个部分，分别为4.2.1的路由映射的细节与4.2.2的proxy请求处理的细节

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

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

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

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

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

如上图所示，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操作不具备原子性的语义。

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

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

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

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

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

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

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

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

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

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

定期冷备归档由于存储服务在运行的过程中可能存在人员误操作数据，机房网络故障，硬件问题导致数据丢失，因此我们需要一些兜底方案，目前主要是单机滚动备份备份最近48小时的数据以及sng的刘备系统来做冷备，以备非预期问题导致数据丢失，能够快速恢复。

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

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

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

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

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

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

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

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

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

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

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

如果部署多个Redis实例，尽量保证同一时刻只有一个子进程执行重写工作

Fork耗费的内存相关日志：AOF rewrite: 53 MB of memory used by copy-on-write，RDB: 5 MB of memory used by copy-on-write

文章详情

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

软考中级精品资料免费领

相关文章

猜你喜欢

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

不支持命令	半支持命令

loop reader	loop writer