pika新特性支持codis slot迁移(来自环信)

张云乾 360基础架构组 2016-12-30

pika新特性支持codis slot迁移(来自环信)

简介

这是pika 开源以来第一个由社区贡献的大功能, 也是infra-360 公众号第一个外部投稿用户, 感谢环信性能工程师张云乾的贡献. 欢迎大家投稿


已经有越来越多的公司在线上使用pika. pika兼容redis绝大数接口,所以之前版本已经支持作为codis的server,替换redis,但是由于不支持codis的slot迁移命令,所以不能在线动态扩容。


现在pika的codis分支已经支持codis的slot迁移,目前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已经在环信的生产环境中使用,获得了一些线上环境的数据:

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

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

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

  4. 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迁移即可。

带来好处

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

  2. 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能实时获取),但需要有以下几点注意:

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

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

    127.0.0.1:9221> slotsreload

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

  3. 如果数据库使用的场景中,有大量过期数据,大量使用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
该讨论提供了两种解决方法:

  1. 如果是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
  2. 如果是codis 3.1版本,可以使用官方版本,并打开多连接,该版本多连接的实现见:https://github.com/CodisLabs/codis/commit/7f72696051ca0992ac3df44c3a95a41727e960f7

总结

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

有任何问题可以在pika讨论群(294254078)交流,也可以在官方github提issue,欢迎试用


本站仅按申请收录文章,版权归原作者所有
如若侵权,请联系本站删除
觉得不错,分享给更多人看到
360基础架构组 热门文章:

基础架构组招聘    阅读/点赞 : 945/8

九问纠删码    阅读/点赞 : 643/15

[LevelDB系列] 数据存储    阅读/点赞 : 324/8

talk about event based concurrency    阅读/点赞 : 239/7

linux write 落盘问题    阅读/点赞 : 230/7

pika 更新至 2.1.4 版本    阅读/点赞 : 192/6

Pika的API和高可运维总结    阅读/点赞 : 181/8

360基础架构组 微信二维码

360基础架构组 微信二维码

数据

阅读 434
点赞 8
更新 1月1日 2:23