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

（原标题：环信实操干货：pika新特性支持codis slot迁移）

简介：已经有越来越多的公司在线上使用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版本，可以使用官方版本，并打开多连接，该版本多连接的实现见：

总结

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

(原标题：环信实操干货：pika新特性支持codis slot迁移)