28 Pika：如何基于SSD实现大容量Redis？ 基

发表于

基本概念

  • 基于大内存的大容量实例在实例恢复、主从同步过程中会引起一系列潜在问题
+ 例如：**恢复时间增长**
+ **主从切换开销大**
+ **缓冲区易溢出**
  • 360 公司 DBA 和基础架构组联合开发的 Pika\
  • pika目标（使用ssd平滑替代redis）\
+ **单实例可以保存大容量数据**，同时避免了实例恢复和主从同步时的潜在问题\
+ **和 Redis 数据类型保持兼容**，可以支持使用 Redis 的应用平滑地迁移到 Pika 上

大内存Redis实例的潜在问题

  • 大内存的潜在问题
+ **RDB生成**和**恢复效率**低  快照


    - **fork**时间久，导致主线程**阻塞**
    - 可能造成swap 内存换到磁盘
+ 全量同步时长增加、缓冲区易溢出


    - 全量同步 RDB文件很大导致全量同步时长增加
    - 主从切换的过程耗时增加，同样会影响业务的可用性

Pika整体架构

  • 整体架构
+ 网络框架
+ Pika线程模块
+ Nemo存储模块
+ RocksDB
+ binlog
  • 网络框架
+ 功能：负责底层网络请求的接收和发送
+ 实现：


    - 对操作系统底层的网络函数进行了封装 socket
    - Pika 线程模块采用了多线程模型来具体处理客户端请求\


        * 请求分发线程（DispatchThread）\
        * 一组工作线程（WorkerThread）（将请求封装成task）\
        * 线程池（ThreadPool）\
+ 调优：增加工作线程数和线程池的线程数
  • Nemo
+ 实现了 Pika 和 Redis 的数**据类型兼容**，降低Pika的学习成本
  • binlog
+ 记录写命令，用于主从节点的命令同步（避免大内存复制，命令比数据小很多）\

Pika 如何基于 SSD 保存更多数据？

  • 基本概念：使用了业界广泛应用的持久化键值数据库RocksDB
  • RocksDB的读写机制（不会占据太大的内存空间）\
+ RocksDB会使用两小块内存空间来交替缓存写入的数据（Memtable1，Memtable2）\


    - 一般为几MB，几十MB
+ 优先写入Memtable1，Memtable1则写入SSD中
+ 此时Memtable2将代替Memtable1
+ 等待Memtable1数据都写完且Memtable2写满，则切换到Memtable1
  • 为什么pika不会出现大文件同步的效率和内存溢出的问题
+ 基于 RocksDB 保存了**数据文件**，不需要再通过**内存快照**进行恢复了\
+ 实现增量命令同步，既节省了内存，还避免了**缓冲区溢出**的问题\
  • pika的优势
+ Pika 使用 RocksDB 把大量数据保存到了 SSD，同时避免了内存快照的生成和恢复问题\
+ Pika 使用 binlog 机制进行主从同步，避免大内存时的影响\

\

Pika 如何实现 Redis 数据类型兼容？

  • 基本概念：RocksDB 只提供了单值的键值对类型，只满足redis的string数据结构
  • Nemo 模块就负责把 Redis 的集合类型转换成单值的键值对\
+ redis集合类型


    - List 和 Set 类型，它们的集合中也只有单值\
    - Hash（field-value） 和 Sorted Set（member-score ） 类型，它们的集合中的元素是成对的\
+ list的转换


    - key：保证多位组成有意义 保存在list的顺序
    - value：前继和后继元素，存活时间，值，版本，存活时间
+ set的转换


    - key：保存set的key和value
    - value：保存版本和存活时间
+ hash的转换


    - key：size hashkey field1
    - value：value1，field2，value2.....
+ zset


    - 类似hash，不过会根据score进行排序

list的转化

\

Pika 的其他优势与不足

  • pika的优点
+ 实例重启快 直接从ssd中获取数据，不需要回放数据\
+ 执行全量同步的风险低，使用binlog（磁盘）实现增量同步，不必担心缓冲区大小的限制
+ 多线程模型，降低了读写ssd对pika的性能影响
  • pika的缺点
+ 访问性能低于redis


    - 将存储从缓存从内存转移到ssd
    - 记录binlog会降低效率
    - 个人感觉数据结构效率很低
  • 适用场景：保存大容量数据是我们的首要需求，那么，Pika 是一个不错的解决方案

\

总结

  • pika优点
+ 既支持 Redis 操作接口，又能支持保存大容量的数据\
+ 支持迁移redis
  • 调优
+ 增加线程数据量，提升并发请求处理能力
+ 使用高配的SSD，提升SSD自身访问性能
  • redis迁移pika
+ Redis 数据迁移到 Pika\


    - aof\_to\_pika -i [Redis AOF文件] -h [Pika IP] -p [Pika port] -a [认证信息]
+ 把 Redis 请求转发给 Pika\

\

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%