pika是什么
pika 是DBA和基础架构组联合开发的类Redis 存储系统，所以完全支持Redis协议，用户不需要修改任何代码，就可以将服务迁移至pika。Pika是一个可持久化的大容量redis存储服务，兼容string、hash、list、zset、set的绝大接口(兼容详情)，解决redis由于存储数据量巨大而导致内存不够用的容量瓶颈，并且可以像redis一样，通过slaveof命令进行主从备份，支持全同步和部分同步。同时DBA团队还提供了迁移工具， 所以户不会感知这个迁移的过程，迁移是平滑的。
与redis的比较
pika相对于redis，最大的不同就是pika是持久化存储，数据存在磁盘上，而redis是内存存储，由此不同也给pika带来了相对于redis的优势和劣势
优势：
- 容量大：Pika没有Redis的内存限制, 最大使用空间等于磁盘空间的大小
- 加载db速度快：Pika 在写入的时候, 数据是落盘的, 所以即使节点挂了, 不需要rdb或者oplog，pika 重启不用加载所有数据到内存就能恢复之前的数据, 不需要进行回放数据操作。
- 备份速度快：Pika备份的速度大致等同于cp的速度（拷贝数据文件后还有一个快照的恢复过程，会花费一些时间），这样在对于百G大库的备份是快捷的，更快的备份速度更好的解决了主从的全同步问题
劣势：
由于Pika是基于内存和文件来存放数据, 所以性能肯定比Redis低一些, 但是我们一般使用SSD盘来存放数据, 尽可能跟上Redis的性能。
适用场景
从以上的对比可以看出, 如果你的业务场景的数据比较大，Redis 很难支撑， 比如大于50G，或者你的数据很重要，不允许断电丢失，那么使用Pika 就可以解决你的问题。 而在实际使用中，pika的性能大约是Redis的50%。
Pika 是 360 DBA 和基础架构组联合开发的类 Redis 存储系统，完全支持 Redis 协议，用户不需要修改任何代码，就可以将服务迁移至 Pika。有维护 Redis 经验的 DBA 维护 Pika 不需要学习成本。
Pika 主要解决的是用户使用 Redis 的内存大小超过 50G、80G 等等这样的情况，会遇到启动恢复时间长，一主多从代价大，硬件成本贵，缓冲区容易写满等问题。Pika 就是针对这些场景的一个解决方案。
Pika is a persistent huge storage service , compatible with the vast majority of redis interfaces (details), including string, hash, list, zset, set and management interfaces. With the huge amount of data stored, redis may suffer for a capacity bottleneck, and pika was born for solving it. Except huge storage capacity, pika also support master-slave mode by slaveof command, including full and partial synchronization. You can also use pika together with twemproxy or codis(pika has supported data migration in codis，thanks left2right) for distributed Redis solution
Pika是一个可持久化的大容量redis存储服务，兼容string、hash、list、zset、set的绝大部分接口(兼容详情)，解决redis由于存储数据量巨大而导致内存不够用的容量瓶颈，并且可以像redis一样，通过slaveof命令进行主从备份，支持全同步和部分同步，pika还可以用在twemproxy或者codis中来实现静态数据分片（pika已经可以支持codis的动态迁移slot功能，目前在合并到master分支，欢迎使用，感谢作者left2right同学提交pr）
Feature
huge storage capacity
compatible with redis interface, you can migrate to pika easily
support master-slave mode (slaveof)
various management interfaces
特点
容量大，支持百G数据量的存储
兼容redis，不用修改代码即可平滑从redis迁移到pika
支持主从(slaveof)
完善的运维命令
pika使用的是多线程模型，使用多个工作线程来进行读写操作，由底层nemo引擎来保证线程安全，线程分为11种：
PikaServer：主线程
DispatchThread：监听端口1个端口，接收用户连接请求
ClientWorker：存在多个（用户配置），每个线程里有若干个用户客户端的连接，负责接收处理用户命令并返回结果，每个线程执行写命令后，追加到binlog中
Trysync：尝试与master建立首次连接，并在以后出现故障后发起重连
ReplicaSender：存在多个（动态创建销毁，本master节点挂多少个slave节点就有多少个），每个线程根据slave节点发来的同步偏移量，从binlog指定的偏移开始实时同步命令给slave节点
ReplicaReceiver：存在1个（动态创建销毁，一个slave节点同时只能有一个master），将用户指定或当前的偏移量发送给master节点并开始接收执行master实时发来的同步命令，在本地使用和master完全一致的偏移量来追加binlog
SlavePing：slave用来向master发送心跳进行存活检测
bgsave：后台dump线程
HeartBeat：master用来接收所有slave发送来的心跳并回复进行存活检测
scan：后台扫描keyspace线程
purge：后台删除binlog线程
大容量 Redis 遇到的问题
1. 恢复时间长
我们线上的 Redis 一般同时开启 rdb 和 aof。
我们知道 aof 的作用是实时的记录用户的写入操作，rdb 是 Redis 某一时刻数据的完整快照。那么恢复的时候一般是通过 rdb + aof 的方式进行恢复，根据我们线上的情况 50G Redis 恢复时间需要差不多 70 分钟。
2. 一主多从，主从切换代价大
Redis 在主库挂掉以后，从库升级为新的主库。那么切换主库以后，所有的从库都需要跟新主做一次全同步，全量同步一次大容量的 Redis 代价非常大。
3. 缓冲区写满问题
为了防止同步缓冲区被复写，dba 给 Redis 设置了 2G 的巨大同步缓冲区，这对于内存资源来讲代价很大。当由于机房之间网络有故障，主从同步出现延迟了大于 2G 以后，就会触发全同步的过程。如果多个从库同时触发全同步的过程， 那么很容易就将主库给拖死。
4. 内存太贵
我们一般线上使用的 Redis 机器是 64G、96G，我们只会使用 80% 的空间。
如果一个 Redis 的实例是 50G，那么基本一台机器只能运行一个 Redis 实例，特别浪费资源。
总结
可以看到在 Redis 比较小的情况下，这些问题都不是问题，但是当 Redis 容量上去以后，很多操作需要的时间也就越来越长了。