pika新特性支持codis slot迁移
简介
已经有越来越多的公司在线上使用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已经在环信的生产环境中使用,获得了一些线上环境的数据:
总结
pika支持codis slot迁移版本带来了一些好处,如动态水平扩容,dbsize实时获取,也带来了一些开销,如磁盘和性能。但它提供了一个开关,一个供你在这之间可以进行权衡的开关;它同时为pika的水平扩展提供了一个选择,一个当你的数据量快速增长带来问题时无痛解决问题的选择。
有任何问题可以在pika讨论群(294254078)交流,也可以在官方github提issue,欢迎试用
本文作者:环信性能工程师张云乾
已经有越来越多的公司在线上使用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已经在环信的生产环境中使用,获得了一些线上环境的数据:
- 当pika容量在500G时,全量同步一次的时间大概在7个小时左右(千M网卡)
- 运行slotsreload命令每秒钟处理key的数据在万级,所以上面针对过期数据使用支持slot迁移的方式是可行的,已经过线上环境验证。
- 在进行slot迁移时,每秒钟迁移的key数量在200~300之间,当数据量大时,迁移需要花费很长时间,但迁移期间不影响线上业务正常使用。
- codis多连接版本可以提升性能2~3倍,完全释放pika的性能
# slotmigrate [yes | no]slotmigrate : yes
部署成功后即可进行使用,和官方的codis没有任何不同,一个大的可以扩容的redis。当codis-server(pika)压力过大需要扩容的使用,按照官方的迁移方法进行slot迁移即可。带来好处 - codis-server集群可以在不停机的情况下进行水平扩容
- dbsize命令可以实时获取当前数据库(pika)中key的数量
$ 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能实时获取),但需要有以下几点注意: [list=1]pika打开slot迁移开关后,磁盘容量会有10%~30%的增加,性能会有10%~15%的下降如果是一个全新的数据库,里面没有数据,在配置文件中打开了迁移开关,即可进行使用和随时进行slot迁移;如果数据库里面已经有数据,通过暂时关机更改配置文件打开开关或者通过命令行打开开关(已立即可以进行正常使用),在进行slot迁移前要先在命令行运行slotsreload命令,[list=1]
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针对过期数据的使用方式进行使用。同名不同类型的keypika支持同名的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该讨论提供了两种解决方法: [list=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 serverbackend_connection_model=server如果是codis 3.1版本,可以使用官方版本,并打开多连接,该版本多连接的实现见:https://github.com/CodisLabs/codis/commit/7f72696051ca0992ac3df44c3a95a41727e960f7
总结
pika支持codis slot迁移版本带来了一些好处,如动态水平扩容,dbsize实时获取,也带来了一些开销,如磁盘和性能。但它提供了一个开关,一个供你在这之间可以进行权衡的开关;它同时为pika的水平扩展提供了一个选择,一个当你的数据量快速增长带来问题时无痛解决问题的选择。
有任何问题可以在pika讨论群(294254078)交流,也可以在官方github提issue,欢迎试用
本文作者:环信性能工程师张云乾