4000余字为你讲透Codis内部工作原理

一、引言
Codis是一个分布式 Redis 解决方案,可以管理数量巨大的Redis节点。个推作为专业的第三方推送服务商,多年来专注于为开发者提供高效稳定的消息推送服务。每天通过个推平台下发的消息数量可达百亿级别。基于个推推送业务对数据量、并发量以及速度的要求非常高,实践发现,单个Redis节点性能容易出现瓶颈,综合考虑各方面因素后,我们选择了Codis来更好地管理和使用Redis。

二、选择Codis的原因
随着公司业务规模的快速增长,我们对数据量的存储需求也越来越大,实践表明,在单个Redis的节点实例下,高并发、海量的存储数据很容易使内存出现暴涨。

此外,每一个Redis的节点,其内存也是受限的,主要有以下两个原因:

一是内存过大,在进行数据同步时,全量同步的方式会导致时间过长,从而增加同步失败的风险;
二是越来越多的redis节点将导致后期巨大的维护成本。

因此,我们对Twemproxy、Codis和Redis Cluster 三种主流redis节点管理的解决方案进行了深入调研。
4000余字为你讲透Codis内部工作原理_第1张图片

推特开源的Twemproxy最大的缺点是无法平滑的扩缩容。而Redis Cluster要求客户端必须支持cluster协议,使用Redis Cluster需要升级客户端,这对很多存量业务是很大的成本。此外,Redis Cluster的p2p方式增加了通信成本,且难以获知集群的当前状态,这无疑增加了运维的工作难度。

而豌豆荚开源的Codis不仅可以解决Twemproxy扩缩容的问题,而且兼容了Twemproxy,且在Redis Cluster(Redis官方集群方案)漏洞频出的时候率先成熟稳定下来,所以最后我们使用了Codis这套集群解决方案来管理数量巨大的redis节点。

目前个推在推送业务上综合使用Redis和Codis,小业务线使用Redis,数据量大、节点个数众多的业务线使用Codis。

我们要清晰地理解Codis内部是如何工作的,这样才能更好地保证Codis集群的稳定运行。下面我们将从Codis源码的角度来分析Codis的Dashboard和Proxy是如何工作的。

三、Codis介绍
Codis是一个代理中间件,用GO语言开发而成。Codis 在系统的位置如下图所示 :
4000余字为你讲透Codis内部工作原理_第2张图片
Codis是一个分布式Redis解决方案,对于上层应用来说,连接Codis Proxy和连接原生的Redis Server没有明显的区别,有部分命令不支持;

Codis底层会处理请求的转发、不停机的数据迁移等工作,对于前面的客户端来说,Codis是透明的,可以简单地认为客户端(client)连接的是一个内存无限大的Redis服务。

Codis分为四个部分,分别是:
Codis Proxy (codis-proxy)
Codis Dashboard
Codis Redis (codis-server)
ZooKeeper/Etcd

Codis架构
4000余字为你讲透Codis内部工作原理_第3张图片

四、Dashboard的内部工作原理

Dashboard介绍
Dashboard是Codis的集群管理工具,所有对集群的操作包括proxy和server的添加、删除、数据迁移等都必须通过dashboard来完成。Dashboard的启动过程是对一些必要的数据结构以及对集群的操作的初始化。

Dashboard启动过程
Dashboard启动过程,主要分为New()和Start()两步。

New()阶段
⭕ 启动时,首先读取配置文件,填充config信息。coordinator的值如果是"zookeeper"或者是"etcd",则创建一个zk或者etcd的客户端。根据config创建一个Topom{}对象。Topom{}十分重要,该对象里面存储了集群中某一时刻所有的节点信息(slot,group,server等),而New()方法会给Topom{}对象赋值。

⭕ 随后启动18080端口,监听、处理对应的api请求。

⭕ 最后启动一个后台线程,每隔一分钟清理pool中无效client。

下图是dashboard在New()时内存中对应的数据结构。

4000余字为你讲透Codis内部工作原理_第4张图片
Start()阶段

⭕ Start()阶段,将内存中model.Topom{}写入zk,路径是/codis3/codis-demo/topom。

⭕ 设置topom.online=true。

⭕ 随后通过Topom.store从zk中重新获取最新的slotMapping、group、proxy等数据填充到topom.cache中(topom.cache,这个缓存结构,如果为空就通过store从zk中取出slotMapping、proxy、group等信息并填充cache。不是只有第一次启动的时候cache会为空,如果集群中的元素(server、slot等等)发生变化,都会调用dirtyCache,将cache中的信息置为nil,这样下一次就会通过Topom.store从zk中重新获取最新的数据填充。)

⭕ 最后启动4个goroutine for循环来处理相应的动作 。
4000余字为你讲透Codis内部工作原理_第5张图片

创建group过程
创建分组的过程很简单。
⭕ 首先,我们通过Topom.store从zk中重新拉取最新的slotMapping、group、proxy等数据填充到topom.cache中。

⭕ 然后根据内存中的最新数据来做校验:校验group的id是否已存在以及该id是否在1~9999这个范围内。

⭕ 接着在内存中创建group{}对象,调用zkClient创建路径/codis3/codis-demo/group/group-0001。

初始,这个group下面是空的。
{

"id": 1,
"servers": [],
"promoting": {},
"out_of_sync": false

}

添加codis server
⭕接下来,向group中添加codis server。Dashboard首先会去连接后端codis server,判断节点是否正常。

⭕ 接着在codis server上执行slotsinfo命令,如果命令执行失败则会导致cordis server添加进程的终结。

⭕ 之后,通过Topom.store从zk中重新拉取最新的slotMapping、group、proxy等数据填充到topom.cache中,根据内存中的最新数据来做校验,判断当前group是否在做主从切换,如果是,则退出;然后检查group server在zk中是否已经存在。

⭕ 最后,创建一个groupServer{}对象,写入zk。
当codis server添加成功后,就像我们上面说的,Topom{}在Start时,有4个goroutine for循环,其中RefreshRedisStats()就可以将codis server的连接放进topom.stats.redisp.pool中

4000余字为你讲透Codis内部工作原理_第6张图片

tips
⭕ Topom{}在Start时,有4个goroutine for循环,其中RefreshRedisStats执行过程中会将codis server的连接放进topom.stats.redisp.pool中;

⭕ RefreshRedisStats()每秒执行一次,里面的逻辑是从topom.cache中获取所有的codis server,然后根据codis server的addr 去topom.stats.redisp.Pool.pool 里面获取client。如果能取到,则执行info命令;如果不能取到,则新建一个client,放进pool中,然后再使用client执行info命令,并将info命令执行的结果放进topom.stats.servers中。

Codis Server主从同步
当一个group添加完成2个节点后,要点击主从同步按钮,将第二个节点变成第一个的slave节点。

⭕ 首先,第一步还是刷新topom.cache。我们通过Topom.store从zk中重新获取最新的slotMapping、group、proxy等数据并把它们填充到topom.cache中。

⭕然后根据最新的数据进行判断:group.Promoting.State != models.ActionNothing,说明当前group的Promoting不为空,即 group里面的两个cordis server在做主从切换,主从同步失败;

group.Servers[index].Action.State == models.ActionPending,说明当前作为salve角色的节点,其状态为pending,主从同步失败;

⭕ 判断通过后,获取所有codis server状态为ActionPending的最大的action.index的值+1,赋值给当前的codis server,然后设置当前作为slave角色的节点的状态为:g.Servers[index].Action.State = models.ActionPending。将这些信息写进zk。

⭕ Topom{}在Start时,有4个goroutine for循环,其中一个用于具体处理主从同步问题。

⭕ 页面上点击主从同步按钮后,内存中对应的数据结构会发生相应的变化:
4000余字为你讲透Codis内部工作原理_第7张图片

⭕ 写进zk中的group信息:

4000余字为你讲透Codis内部工作原理_第8张图片
tips

Topom{}在Start时,有4个goroutine for循环,其中一个便用于具体来处理主从同步。具体怎么做呢?

首先,通过Topom.store从zk中重新获取最新的slotMapping、group、proxy等数据填充到topom.cache中,待得到最新的cache数据后,获取需要做主从同步的group server,修改group.Servers[index].Action.State == models.ActionSyncing,写入zk中。

其次,dashboard连接到作为salve角色的节点上,开启一个redis事务,执行主从同步命令:

c.Send(“MULTI”) —> 开启事务
c.Send(“config”, “set”, “masterauth”, c.Auth)
c.Send(“slaveof”, host, port)

c.Send(“config”, “rewrite")
c.Send(“client”, “kill”, “type”, “normal")
c.Do(“exec”) —> 事物执行

⭕ 主从同步命令执行完成后,修改group.Servers[index].Action.State == “synced”并将其写入zk中。至此,整个主从同步过程已经全部完成。

codis server在做主从同步的过程中,从开始到完成一共会经历5种状态:

""(ActionNothing) --> 新添加的codis,没有主从关系的时候,状态为空
pending(ActionPending) --> 页面点击主从同步之后写入zk中
syncing(ActionSyncing) --> 后台goroutine for循环处理主从同步时,写入zk的中间状态
synced --> goroutine for循环处理主从同步成功后,写入zk中的状态
synced_failed --> goroutine for循环处理主从同步失败后,写入zk中的状态

slot分配
上文给Codis集群添加了codis server,做了主从同步,接下来我们把1024个slot分配给每个codis server。Codis给使用者提供了多种方式,它可以将指定序号的slot移到某个指定group,也可以将某个group中的多个slot移动到另一个group。不过,最方便的方式是自动rebalance。

通过Topom.store我们首先从zk中重新获取最新的slotMapping、group、proxy等数据填充到topom.cache中,再根据cache中最新的slotMapping和group信息,生成slots分配计划 plans = {0:1, 1:1, … , 342:3, …, 512:2, …, 853:2, …, 1023:3},其中key 为 slot id, value 为 group id。接着,我们按照slots分配计划,更新slotMapping信息:Action.State = ActionPending和Action.TargetId = slot分配到的目标group id,并将更新的信息写回zk中。

Topom{}在Start时,有4个goroutine for循环,其中一个用于处理slot分配。

SlotMapping:

4000余字为你讲透Codis内部工作原理_第9张图片
tips
● Topom{}在Start时,有4个goroutine for循环,其中ProcessSlotAction执行过程中就将codis server的连接放进topom.action.redisp.pool中了。

● ProcessSlotAction()每秒执行一次,待里面的一系列处理逻辑执行之后,它会从topom{}.action.redisp.Pool.pool中获取client,随后在redis上执行SLOTSMGRTTAGSLOT命令。如果client能取到,则dashboard会在redis上执行迁移命令;如果不能取到,则新建一个client,放进pool中,然后再使用client执行迁移命令。

SlotMapping中action对应的7种状态:
4000余字为你讲透Codis内部工作原理_第10张图片
我们知道Codis是由ZooKeeper来管理的,当Codis的Codis Dashbord改变槽位信息时,其他的Codis Proxy节点会监听到ZooKeeper的槽位变化,并及时同步槽位信息。

4000余字为你讲透Codis内部工作原理_第11张图片
总结一下,启动dashboard过程中,需要连接zk、创建Topom这个struct,并通过18080这个端口与集群进行交互,然后将该端口收到的信息进行转发。此外,还需要启动四个goroutine、刷新集群中的redis和proxy的状态,以及处理slot和同步操作。

五、Proxy的内部工作原理

proxy启动过程
proxy启动过程,主要分为New()、Online()、reinitProxy()和接收客户端请求()等4个环节。

New()阶段
⭕ 首先,在内存中新建一个Proxy{}结构体对象,并进行各种赋值。
⭕ 其次,启动11080端口和19000端口。
⭕ 然后启动3个goroutine后台线程,处理对应的操作:
●Proxy启动一个goroutine后台线程,并对11080端口的请求进行处理;
●Proxy启动一个goroutine后台线程,并对19000端口的请求进行处理;
●Proxy启动一个goroutine后台线程,通过ping codis server对后端bc予以维护 。

4000余字为你讲透Codis内部工作原理_第12张图片

Online()阶段
⭕ 首先对model.Proxy{}的id进行赋值,Id = ctx.maxProxyId() + 1。若添加第一个proxy时, ctx.maxProxyId() = 0,则第一个proxy的id 为 0 + 1。

⭕ 其次,在zk中创建proxy目录。

⭕之后,对proxy内存数据进行刷新reinitProxy(ctx, p, c)。

⭕ 第四,设置如下代码:
online = true
proxy.online = true
router.online = true
jodis.online = true

⭕ 第五,zk中创建jodis目录。

4000余字为你讲透Codis内部工作原理_第13张图片

reinitProxy()
⭕Dashboard从zk[m1] 中重新获取最新的slotMapping、group、proxy等数据填充到topom.cache中。根据cache中的slotMapping和group数据,Proxy可以得到model.Slot{},其里面包含了每个slot对应后端的ip与port。建立每个codis server的连接,然后将连接放进router中。

⭕ Redis请求是由sharedBackendConn中取出的一个BackendConn进行处理的。Proxy.Router中存储了集群中所有sharedBackendConnPool和slot的对应关系,用于将redis的请求转发给相应的slot进行处理,而Router里面的sharedBackendConnPool和slot则是通过reinitProxy()来保持最新的值。

总结一下proxy启动过程中的流程。首先读取配置文件,获取Config对象。其次,根据Config新建Proxy,并填充Proxy的各个属性。这里面比较重要的是填充models.Proxy(详细信息可以在zk中查看),以及与zk连接、注册相关路径。

随后,启动goroutine监听11080端口的codis集群发过来的请求并进行转发,以及监听发到19000端口的redis请求并进行相关处理。紧接着,刷新zk中数据到内存中,根据models.SlotMapping和group在Proxy.router中创建1024个models.Slot。此过程中Router为每个Slot都分配了对应的backendConn,用于将redis请求转发给相应的slot进行处理。

六、Codis内部原理补充说明
Codis中key的分配算法是先把key进行CRC32,得到一个32位的数字,然后再hash%1024后得到一个余数。这个值就是这个key对应着的槽,这槽后面对应着的就是redis的实例。
4000余字为你讲透Codis内部工作原理_第14张图片
slot共有七种状态:nothing(用空字符串表示)、pending、preparing、prepared、migrating、finished。

如何保证slots在迁移过程中不影响客户端的业务?
⭕ client端把命令发送到proxy, proxy会算出key对应哪个slot,比如30,然后去proxy的router里拿到Slot{},内含backend.bc和migrate.bc。如果migrate.bc有值,说明slot目前在做迁移操作,系统会取出migrate.bc.conn(后端codis-server连接),并在codis server上强制将这个key迁移到目标group,随后取出backend.bc.conn,访问对应的后端codis server,并进行相应操作。

七、Codis的不足与个推使用上的改进

Codis的不足
⭕ 欠缺安全考虑,codis fe页面没有登录验证功能;
⭕ 缺乏自带的多租户方案;
⭕ 缺乏集群缩容方案。

个推使用上的改进
⭕ 采用squid代理的方式来简单限制fe页面的访问,后期基于fe进行二次开发来控制登录;
⭕ 小业务通过在key前缀增加业务标识,复用相同集群;大业务使用独立集群,独立机器;
⭕ 采用手动迁移数据、腾空节点、下线节点的方法来缩容。

八、全文总结
Codis作为个推消息推送一项重要的基础服务,性能的好坏至关重要。个推将Redis节点迁移到Codis后,有效地解决了扩充容量和运维管理的难题。未来,个推还将继续关注Codis,与大家共同探讨如何在生产环境中更好地对其进行使用。

4000余字为你讲透Codis内部工作原理_第15张图片

你可能感兴趣的:(运维,redis)