01
业务挑战
随着业务量快速发展，用户对 Redis 这种速查KV缓存型数据库需求越来越高，不仅要快，还要持久化安全。Redis 自身aof 可保证持久化数据，但是随着内存增长，高内存下aof文件过大，bgrewriteof 重写往往会导致业务连接超时等问题产生，同时进行扩容以及分析rdb等也会对系统内存造成挑战，还有重要的一点就是内存太贵了, 用不起用不起～为此Pika 诞生了～360 DBA和基础架构组联合开发的类Redis 存储系统，一种基于硬盘存储的完全兼容Redis协议，解决Redis由于存储数据量巨大而导致内存不够用的容量瓶颈，并且可以像Redis一样，通过slaveof命令进行主从备份，支持全同步和部分同步，同时DBA团队还提供了迁移工具，所以用户不会感知这个迁移的过程，迁移是平滑的。
02
Pika vs Redis
目前360 KV数据库应用中主要包含 Redis和 Pika ，Pika 主要的定位目标并不是取代Redis，而是Redis 的一个补充，是在使用 Redis容量过大的场景下面的一个解决方案，同时用硬盘换内存节约成本。
01 优势
① 容量大：Pika没有 Redis的内存限制, 最大使用空间等于磁盘空间的大小
② 加载db速度快：Pika在写入的时候, 数据是落盘的, 所以即使节点挂了, 不需要rdb或者oplog。Pika重启不用加载所有数据到内存就能恢复之前的数据, 不需要进行回放数据操作
③ 备份速度快：Pika备份的速度大致等同于cp的速度（拷贝数据文件后还有一个快照的恢复过程，会花费一些时间），这样在对于百G大库的备份是快捷的，更快的备份速度更好的解决了主从的全同步问题
02 劣势
由于 Pika是基于内存和文件来存放数据, 所以性能肯定比 Redis低一些, 但是我们一般使用SSD盘来存放数据, 尽可能跟上 Redis的性能。
下面是 Pika 多线程VS Redis 单线程性能压测，在多线程Pika 测试下大部分常用 command性能都可以和 Redis媲美甚至高出。
03
360 Pika使用现状
Pika 目前在360公司内部有2000+的主从实例以及在运行, 公司目前的大部分业务80%以上业务都在使用, 无线浏览器, 花椒, 云盘, 信息流，搜索等等。基于codis的pika集群可支撑百万 qps以及上TB容量，近10套集群也已在搜索/反作弊业务上线使用。同时Pika在公司外部也有大量的使用, 具体可以看 user list: Qihoo360/Pika 当然这只是一部分的使用用户。
04
业务收益
如下图：
05
HULK云平台数据库自动化运维
HULK 云平台是奇虎360应用开发部于2012年10月开始内部开发，并在2013年1月正式推出的供公司内部使用的私有云计算平台，是简单高效的分布式Web服务开发、运行平台。我们把pika服务集成在了 hulk平台中，为用户提供了统一的类redis服务入口。
01 Pika用户端申请
应用可以通过HULK 用户端发起申请Pika新实例，可选择不同套餐ABCD 分别对应不同的存储容量大小最小是10GB，最大是100GB。如需更大存储容量联系DBA进行申请，可以选择单机房或者多机房，架构分为一主多从和机房自洽（多机房共用相同端口独立主从结构）。
02 Pika管理端审核
应用通过 HULK用户端申请 Pika后，DBA可以在 HULK 管理端进行审批操作。
03 Pika管理端操作页面
管理端可进行“新建实例”,“下线实例”,“维护实例”,“修改配置”，“同机房/跨机房切主”,“实例端口扩容”等常用操作。非常方便DBA进行日常运维操作,当实例故障需要处理的时候点“维护”来避免频繁告警；当主从切换后，HULK 自动对“角色”进行甄别刷新；还可以通过“编辑”按钮对数据库参数进行在线编辑；点击“控制台”可以直接登陆对应机器数据库进行操作；同时当整台机器宕机的时候可以通过“端口克隆”来把机器上所有的端口克隆复制到新机器然后报修。
通过lvs 给每个端口挂在读写以及只读vip可供业务选择实现读写分离和负载均衡。
04 Pika监控指标查看
HULK 用户端业务可查看对应端口的监控信息，比如当前容量使用信息/客户端连接信息/访问统计/连接数/内存/cpu/keys等统计信息
05 Pika告警及故障自愈
结合zabbix告警，通过api接口和wonder告警平台发送告警到公司自研交流软件推推以及短信。常见告警通过自愈系统自动进行修复，极大减少人工成本。我们的告警自愈系统可以针对Pika主从复制错误/角色错误/宕机快速恢复主从架构等及时恢复，有效降低了业务影响时间。
06 Pika数据迁移
业务经常因为内存不断增长导致套餐超值无法申请，逐渐转化为 Pika使用，需要由 Redis->Pika。我们在 HULK用户端 Redis DTS 集成了此功能来进行端口间数据迁移，也可实现 Redis数据迁移 [redis/pika 统一为redis数据库类型。
07 Pika升级
当前360已升级大部分版本为3.2.8，部分是最新版本3.3.6，建议升级到3.3.6。
升级到2.3 升级到3.0
① 扩容端口从库
② 扩容完成后所有从节点执行相关处理逻辑
Pika 26-30主要涉及到bgsave一份数据，然后对备份数据的格式转化，转化时间比看数据量，不过有的无用数据比较多，没compact 的，即使一条也转化的很慢，转化完成后更改替换数据目录启动新版本，然后改identify-binlog-type old ，并且根据info点位同步主从。
③ 从库升级完成后, 切主, 切主后所有节点升级到3.0版本
3.0 升级到 3.2
① 主从同时跑升级逻辑，执行时间间隙不太长一般都能成功，如果失败了的话，就 做个全同步就好了
Pika 30-32 主要是更换数据目录，由单db改为多db，详细的可以看下脚本或者 github 的升级流程https://github.com/Qihoo360/Pika/wiki/%e5%a6%82%e4%bd%95%e5%8d%87%e7%ba%a7%e5%88%b0Pika3.1%e6%88%963.2
08 Pika备份恢复
备份后端主要通过agent实现远程调用，每天根据备份策略进行bgsave备份,并同步到远程备份机。
HULK可以查看每天端口的备份情况,失败有日志可以参考进行修复。
备份恢复检查，备份成功后会随机挑选端口进行数据恢复测试并以邮件的形式巡检发送出来。
06
总结
360 已使用 Pika至少 5年，线上使用数千实例来支撑各个业务线，一直非常稳定。我们研发和 DBA 致力于打造更好的 Pika 服务和用户体验，在社区不断更新新功能和修复bug以及回复社区问题，捐赠给 OpenAtom 基金会后，越来越多的行业和开发者参与进来。相信 Pika 未来应用会越来越广泛，希望和广大知识爱好者一起进步。
