类Redis大容量存储pika发布2.2正式版

绝代码农

pika是360 WEB平台部DBA与基础架构组合作开发的大容量类Redis存储，力求在完全兼容Redis协议、继承Redis便捷运维设计的前提下通过持久化存储的方式解决Redis在大容量场景下的问题，如恢复时间慢、主从同步代价高、单线程相对脆弱、承载数据较有限、内存成本高昂等问题

pika2.2 改进点及BUG修复列表

• 更新rocksdb 到5.0.1，并将其插件化，后续可以动态升级rocksdb 版本
  
• 新增 geo 接口及 hyperloglog 接口（感谢Leviathan1995同学的支持）
  
• 对底层网络框架pink 进行优化，解决极慢请求加大量短连接场景下可能出现的fd 溢出问题. 
  注：现版本pika 在遇到一个极慢的请求例如keys *的时候会将某一个线程阻塞（类似Redis的hang住），此时后续请求会一直处于工作线程的队列中， 随着连接变多最终造成fd 句柄数过多进程crash. 优化后我们增加了fd 句柄数限制同时优化了线程任务分配逻辑， 在2.2版本中即使有慢请求后续的连接也会被分配给空闲线程， 不会再出现此类问题
  
• 优化写入性能， 在引擎层开启并行写， 写入接口性能都有一定程度的提高，例如 set 性能提高30%
  
• 提高了 range 接口的性能
  
• 多数据结构过期后残留的meta信息已可通过 compact 命令回收（如果你的实例存在大量的过期多数据结构，本次升级后执行 compact 命令会为你释放更多空间）
  
• 修复在 scan 过程中由于bug导致 scan 阻塞的问题
  
• 修复在 range 操作中可能出现无法读出确实存在的key的问题
  
• 修复了 bgsave 和 info 同时执行有极小概率出现死锁的问题
  
• 虚拟的dbnum现在有了上限，最多为16个（db0 - db15），以解决一些Redis管理工具因为pika无dbnum上限而卡在 select 的问题
  
• 完整支持rocksdb多线程 compact ，提高compaction速度
  
• 配置文件增加新参数 max-background-flushes ， max-background-compactions ， max-bytes-for-level-multiplier 具体功能请参考wiki
  

github：https://github.com/Qihoo360/pika  
 
pika技术交流群：294254078
 
 

如果你还不知道pika是什么，请浏览下方的简介
pika是360 WEB平台部DBA与基础架构组合作开发的大容量类Redis存储，力求在兼容Redis协议、运维方式的前提下通过持久化存储的方式解决其在大容量场景下的问题，如恢复时间慢、主从同步代价高、单线程相对脆弱、承载数据较有限、内存成本高昂等问题，它具有如下特点：

• pika完全兼容Redis协议，所以它没有自己的专用客户端，请直接使用Redis的客户端连接pika，因此从Redis迁移到pika几乎不需要修改程序代码
  
• pika兼容绝大多数的Redis接口（80%以上），具体接口兼容列表请参考wiki，个别接口使用稍有不同，此外我们一直在不断提高接口兼容数量
  
• pika为持久化存储，数据自动落盘无需额外设置，无需担心突然断电了数据怎么办
  
• pika支持多线程并对工作线程的分配进行了优化，在极端场景下pika比Redis存活率更高，例如一个可以让Redis完全hang住的keys 命令在12线程的pika中你需要连续至少发送12次keys 才可达到一样的hang住效果，而pika的线程数量可按照你的喜好进行设置
  
• pika是廉价的，它占用很少的内存资源并自带压缩功能，在实际测试中Redis数据导入pika后有3~8倍的压缩比，也就是80G的Redis内存数据导入到pika后只有10~30G磁盘数据，非常节约，同时pika支持多种压缩算法供你选择
  
• pika继承了Redis的便捷运维设计，如果你有Redis运维经历那么pika可轻松上手，另外我们对部分运维相关功能进行了一些改进，例如：
  

• slaveof一键创建主从结构（全自动全量同步并自动转换为增量同步）
  
• 同样支持Redis的级联集群模式
  
• 重启无需重新导入数据，数据秒级全自动加载
  
• 同步使用二进制日志为媒介，这种持久化日志的同步方案使从库不再有Redis从库的“重启重做”、“断网太久重做”等令人头疼的问题，从库灾难恢复后可以通过灾难前的binlog位置继续进行同步
  
• 故障切主后从库无需重灌数据，从库到新主库秒级挂载，同步自动续传，大幅度提高故障后整个集群的恢复时间
  
• 无阻塞快照式全量热备，在备份速度极快（毫秒即可完成）的同时备份对空间只有很小的占用，同时我们提供了增量备份工具
  
• pika提供多用户（管理员/普通用户）以及多用户“命令黑名单”功能，可以通过该功能对用户屏蔽风险命令，而管理员账户则不受限制
  
• 其它细小改进不再一一阐述
  

• pika的状态输出在设计中尽量靠近Redis，所以你现在的部分Redis监控策略可以直接用于pika而无需修改
  
• pika已兼容codis（感谢环信公司left2right同学对pika codis的支持）
  
• 无论是迁移到pika还是从pika迁出都非常简单，我们提供了如下工具：
  

• Redis -> pika迁移工具，它基于aof，能够全量 + 自动增量将aof中的数据发送到pika
  
• ssdb -> pika迁移工具
  
• pika -> Redis迁移工具
  

其他“特性”：

• pika有三个兼职产品经理负责功能改进、BUG跟踪、性能及功能测试，他们的另一个身份是DBA
  
• 据说pika开发组（WEB平台 基础架构组）可能是国内 “最了解” rocksdb 的团队之一
  
• pika社区用户没有小白鼠，pika所有新版都会完全跑完接近1500个测试用例然后优先在内部使用，达到稳后才会公开发布
  
• pika在内部使用的版本和开源版本完全一致
  

 

pika定位于Redis的场景补充，我们选取了一些可能适合pika的场景

• 使用Redis导致服务器成本太高
  
• 数据量巨大（超过单机内存上限）但又不好分片
  
• 经常出现时间复杂度很高的请求让Redis间歇性阻塞
  
• 希望数据能够真正意义上的持久化而非AOF
  
• 在Redis中存放了大量数据但又无法忍受灾难后相当长的数据重新加载时间
  
• 读写分离且不希望故障切主后影到从库
   
  

pika用户现状
360内部

实例数量：已达500+
承载请求：400亿次/天
总数据量：4T（此处为单份数据未记入冗余部分，例如一个主从集群2个实例每个实例20G共40G，此处只按一个实例的数据量20G计算），换算到Redis大致相当于20T内存

 
社区用户

请参考github上的社区用户LOGO或加入QQ群了解更多