环信实操干货：pika新特性支持codis slot迁移

　　张云乾童鞋内部分享

　　环信即时通讯云使用案例

　　背景介绍

　　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无感知