环信实操干货:pika新特性支持codisslot迁移

标签:环信

访客:6132  发表于:2017-01-03 12:12:41

简介:已经有越来越多的公司在线上使用pika. pika兼容redis协议,之前版本已经支持作为codis的server,但是由于不支持codis的slot迁移操作,所以还不能在线动态扩容。现在pika的codis分支已经支持codis的slot迁移,目前该版本已经在环信线上稳定运行, 每天承载数亿的访问量, 这个大feature 由环信云乾同学开发测试完成。

张云乾童鞋内部分享

环信即时通讯云使用案例

背景介绍

pika在环信的即时通讯云平台系统中使用,用来存储消息内容和日志,目前在部分集群中数据量已经达到数TB,QPS在数十万级别。这些数据最早存储在mysql里面,但mysql性能有限,而且扩容不方便。我们评估了下codis,能解决我们在mysql里面面临的性能及扩容问题,在一段时间用codis存储这些数据。但随着数据量级增长,TB级别的数据存储在内存里面,成本过于昂贵。后来了解到pika数据存储在磁盘里面,而且兼容redis协议及命令,可以挂载在codis proxy后面做server,这样既保留codis proxy的高性能,又能解决TB级数据量的存储成本问题。但pika还不支持codis的slot迁移,当压力上涨时,扩容是个问题。通过研究codis及pika的实现,在pika上开发实现了codis的slot迁移。目前已在生产环境中使用,运行良好,考虑到该功能能帮助更多的人解决一些实际的问题,我们经过再三测试验证后向官方提交了PR

线上数据

支持slot迁移版本的pika已经在环信的生产环境中使用,获得了一些线上环境的数据:

当pika容量在500G时,全量同步一次的时间大概在7个小时左右(千M网卡)

运行slotsreload命令每秒钟处理key的数据在万级,所以上面针对过期数据使用支持slot迁移的方式是可行的,已经过线上环境验证。

在进行slot迁移时,每秒钟迁移的key数量在200~300之间,当数据量大时,迁移需要花费很长时间,但迁移期间不影响线上业务正常使用。

codis多连接版本可以提升性能2~3倍,完全释放pika的性能

pika codis slot 功能介绍

部署方法

codis部署方式没有改动,只是在添加codis-server(redis)的地方部署上支持codis slot迁移的pika,该版本pika部署和之前的pika部署方式一样,只是配置文件中需要添加一样,以打开支持迁移的开关:

# slotmigrate [yes | no]

slotmigrate : yes

使用方法

部署成功后即可进行使用,和官方的codis没有任何不同,一个大的可以扩容的redis。当codis-server(pika)压力过大需要扩容的使用,按照官方的迁移方法进行slot迁移即可。

带来好处

codis-server集群可以在不停机的情况下进行水平扩容

dbsize命令可以实时获取当前数据库(pika)中key的数量

注意事项

slot迁移开关

出于和pika之前官方版本更好的兼容,以及用户升级到支持迁移的pika版本操作更方便的考虑。在设计实现pika支持codis slot迁移时,设计并实现了slot迁移开关,该开关可以通过配置文件进行开关或者关闭(即上面配置文件改动的地方,yes是打开,no是关闭),也可以通过redis-cli的config set slotmigrate进行在线的打开或者关闭:

$ redis-cli -h 127.0.0.1 -p 9221 config set slotmigrate yes

$ redis-cli -h 127.0.0.1 -p 9221 config set slotmigrate no

当关闭开关时,pika不支持slot迁移,和之前版本的pika没有区别(dbsize也不能实时获取);当打开开关时,支持slot迁移(dbsize能实时获取),但需要有以下几点注意:

pika打开slot迁移开关后,磁盘容量会有10%~30%的增加,性能会有10%~15%的下降

如果是一个全新的数据库,里面没有数据,在配置文件中打开了迁移开关,即可进行使用和随时进行slot迁移;如果数据库里面已经有数据,通过暂时关机更改配置文件打开开关或者通过命令行打开开关(已立即可以进行正常使用),在进行slot迁移前要先在命令行运行slotsreload命令,

127.0.0.1:9221> slotsreload

该命令是一个在后台运行的命令,类似bgsave模式,可以通过info命令查看slotsreload是否运行结束,在运行结束后才可以进行迁移。

如果数据库使用的场景中,有大量过期数据,大量使用expire等设置key过期的命令,建议不要在配置文件中打开开关(那些过期的数据,在slot里面没有进行过期删除,会导致数据累积,后面会考虑改进这点),可以考虑在需要迁移前在命令行打开开关,然后运行slotsreload命令,在slotsreload命令运行结束后,进行迁移,迁移完成后在命令行运行slotsdel命令进行收尾工作(释放磁盘占用),命令后面跟需要清理掉slot,如下方式

$ 127.0.0.1:9221> slotsdel 1013 990

额外开销

如上面所说,pika支持slot迁移会使用更多一些的磁盘,性能上会有一些下降。如果对磁盘使用或者性能有很高的要求,则可以按照上面3针对过期数据的使用方式进行使用。

同名不同类型的key

pika支持同名的key有kv,hash,list,set, zset等5种类型,但如果要使用pika支持slot迁移,不要使用同名但不同类型的key,如不要:set test1 100后再lpush test1 a b c,产生同名不同类型的key。在支持slot迁移的pika中使用同名但不同类型的key,迁移的时候会丢失那些同名的key。

codis多连接

codis 2.0及之前版本proxy和后端server是使用的单连接,当后端server是redis时,这个性能还是很不错的,但当后面是pika、ssdb等磁盘数据库时,单连接严重限制了后端server的性能,需要让codis支持多连接,针对多连接这个问题的讨论见:https://github.com/CodisLabs/codis/pull/1007

该讨论提供了两种解决方法:

如果是codis 2.0版本可以使用https://github.com/left2right/codis ,编译后在proxy的配置文件中作如下增加;

# Proxy connections number model with backend server: server/slot, server means only one connection between proxy and backend server,

# slot means every slot has one connection between proxy and backend server, default is server

backend_connection_model=server

如果是codis 3.1版本,可以使用官方版本,并打开多连接,该版本多连接的实现见:https://github.com/CodisLabs/codis/commit/7f72696051ca0992ac3df44c3a95a41727e960f7

总结

pika支持codis slot迁移版本带来了一些好处,如动态水平扩容,dbsize实时获取,也带来了一些开销,如磁盘和性能。但它提供了一个开关,一个供你在这之间可以进行权衡的开关;它同时为pika的水平扩展提供了一个选择,一个当你的数据量快速增长带来问题时无痛解决问题的选择。

关于Pika

Pika是360 DBA和基础架构组联合开发的类redis存储系统, 使用Redis协议,兼容redis绝大多数命令(String,Hash,List,ZSet,Set),用户不需要修改任何代码, 就可以将服务迁移至pika。pika主要是使用持久化存储来解决redis在内存占用超过50G,80G时遇到的如启动恢复时间长,主从同步代价大,硬件成本贵等问题,并且在对外用法上尽可能做到与redis一致,用户基本上对后端是redis或pika无感知。

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");