Redis学习笔记28——Pika：如何基于SSD实现大容量Redis

着业务数据的增加，就需要 Redis 能保存更多的数据。你可能会想到使用 Redis 切片集群，把数据分散保存到多个实例上。但是这样做的话，会有一个问题，如果要保存的数据总量很大，但是每个实例保存的数据量较小的话，就会导致集群的实例规模增加，这会让集群的运维管理变得复杂，增加开销。如果增加单个实例的内存容量，但是在实例恢复，主从同步过程中会引起恢复时间增长、主从切换开销大、缓冲区容易溢出。

可以使用基于SSD来实现大容量的Redis实例，即Pika键值数据库。

Pika有两个特点：

• 单实例可以保存大容量数据，同时避免了实例恢复和主从同步时的潜在问题；
• 和 Redis 数据类型保持兼容，可以支持使用 Redis 的应用平滑地迁移到 Pika 上

使用大内存Redis实例的潜在问题

• 内存快照 RDB 生成慢
• 恢复效率低
• 主从节点全量同步时长增加
• 复制缓冲区容易溢出

RBD生成慢

内存大小和内存快照 RDB 的关系是非常直接的：实例内存容量大，RDB 文件也会相应增大，那么，RDB 文件生成时的 fork 时长就会增加，这就会导致 Redis 实例阻塞。

恢复效率低

RDB 文件增大后，使用 RDB 进行恢复的时长也会增加，会导致 Redis 较长时间无法对外提供服务。

主从节点全量同步时长增加

主从节点间的同步的第一步就是要做全量同步。全量同步是主节点生成 RDB 文件，并传给从节点，从节点再进行加载。试想一下，如果 RDB 文件很大，肯定会导致全量同步的时长增加，效率不高

复制缓冲区容易溢出

一旦缓冲区溢出了，主从节点间就会又开始全量同步，影响业务应用的正常使用。如果我们增加复制缓冲区的容量，这又会消耗宝贵的内存资源。