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更多信息请点击左上方公众号名称进行关注
欢迎通过HULK公众号反馈pika相关bug及提交改进点
如果你还不知道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迁出都非常简单,我们提供了如下工具:
|