陈宗志：大容量redis存储方案 Pika

2020-03-01 238浏览

  • 1.7 大容量redis存储方案--Pika 1 0 2 C C A S 陈宗志 360基础架构组技术经理
  • 2.简介 • 13年入职360 基础架构组 – Bada – Pika – Zeppelin 2 C C A S 7 1 0 – Mario, Pink, slash, floyd •https://github.com/Qihoo360
  • 3.概要 • 存在问题 • 分析问题 • 解决问题 2 C C A S • Pika vs redis 7 1 0
  • 4.Introduction • Pika 是DBA 和 基础架构团队一起设计开发的 大容量redis的解决方案 2 C C A S 7 1 0 • 完全兼容redis 协议, 用户不需要修改任何代码 进行迁移
  • 5.Pika User • Redis实例数量：6000+个 • 日访问量：5000+亿 2 C C 日访问量：1000+亿 A S • Pika数据数量：1000+个 • • 覆盖率：80%以上业务线 • 单份数据体积：6.8T 7 1 0
  • 6.2 C C A S 7 1 0
  • 7.Pika 定位 Pika 的出现并不是为了替代 Redis，而是 Redis 的场景补充。 7 1 0 2 C C A 捷运维设计的前提下通过持久化存储的方式解决 S Pika 力求在完全兼容 Redis 协议、继承 Redis 便 Redis 在大容量场景下的问题
  • 8.Redis 问题 • 恢复时间长 7 1 0 • 一主多从, 主从切换代价大 • 2 缓冲区写满问题 CC A S • 成本问题
  • 9.Redis 问题 • 恢复时间长 7 1 0 2 C – 50G redis 回复时间70分钟 C A S – 同时开启aof 和 rdb
  • 10.Redis 问题 • 一主多从, 主从切换代价大 17 0 2 C – 主库挂掉后升级从库, 所有的从库全部重传数 C A S 据
  • 11.Redis 问题 • 缓冲区写满问题 7 1 0 – 内存是昂贵资源, 缓冲区一般设置2G 2 C C A – 网络原因很容易将数据堵死, 那么就会发生大 S 量数据重传
  • 12.Redis 问题 • 内存太贵 7 1 0 – 线上使用的redis 机器是 64G, 96G. 只使用 2 C C A – 如果一个redis S 的实例是50G, 那么基本一台 80% 的空间. 机器只能运行一个redis 实例. 特别的浪费资 源
  • 13.Redis 问题 90/GB VS 2.6/GB 2 C C A S 7 1 0 30倍的差距
  • 14.问题分析 • 成本问题 • 可用性问题 • 同步问题 • 易用性问题 2 C C A S 7 1 0
  • 15.问题分析 • 尽可能兼容redis 协议 • 使用基于磁盘的存储引擎rocksdb 实现多 7 1 0 2 C 数据接口接口 C A S • 网络库 • 添加binlog 模块
  • 16.Pika 整体结构 2 C C A S 7 1 0
  • 17.网络模块--Pink • 基础架构团队开发网络编程库, 支持pb, redis, pg, http等协议. • 抽象各种不同类型线程 – DispatchThread 2 C C A S – WorkThread – BGThread 7 1 0 •https://github.com/Qihoo360/pink
  • 18.网络模块--Pink • 稳定行, 在各个项目中使用4年多 • 易用性 • 高性能 2 C C A S 7 1 0
  • 19.网络模块--Pink class MyPbConn : publicpink::PbConn{Public:MyPbConn(int fd,std::stringip_port,pink::Thread*self_thread_ptr = NULL) :pink::PbConn(fd, ip_port) { res_ = dynamic_cast(&message_); } ~MyPbConn() {} int DealMessage() { 2 C C A S 7 1 0 message_.ParseFromArray(rbuf_ + cur_pos_ - header_len_, header_len_); message_.set_name("hello " + message_.name()); uint32_t u =htonl( message_.ByteSize()); memcpy(static_cast(wbuf_), static_cast(&u), COMMAND_HEADER_LENGTH); message_.SerializeToArray(wbuf_ + COMMAND_HEADER_LENGTH, PB_MAX_MESSAGE); set_is_reply(true); }
  • 20.网络模块--Pink 2 C C A S 7 1 0
  • 21.存储引擎--Nemo • Nemo – Pika 的存储引擎, 基于Rocksdb 实现. 实现了Hash, 7 1 0 List, Set, Zset 等数据结构 2 C C A 对SSD 盘友好 – Rocksdb 使用的本地硬盘, S – Rocksdb 启动只需要加载log 文件 –https://github.com/Qihoo360/nemo
  • 22.存储引擎--Nemo 2 C C A S 7 1 0
  • 23.存储引擎--Nemo 7 1 – DB->Put(wop, h6myhashfield1,Hello01477671118) 0 2 C – DB->Put(wop, Hmyhash11477671118, 6) C A S • HSET myhash field1 "Hello"
  • 24.存储引擎--Nemo 2 C C A S 7 1 0
  • 25.存储引擎--Nemo 7 1 – DB->Put(wop, l6mylist6, 57world01477671118) 0 2 C – DB->Put(wop, Lmyhash11477671118, 6071) C A S • LPUSH mylist "world"
  • 26.日志模块--Binlog • Binlog 7 1 0 – 顺序写文件, 通过Index + offset 进行同步点 2 C C A – 解决了缓冲区小的问题 S 检查 – 支持全同步 + 增量同步
  • 27.日志模块--Binlog 2 C C A S 7 1 0
  • 28.主从同步-- slaveof 2 C C A S 7 1 0
  • 29.主从同步-- slaveof 2 C C A S 7 1 0
  • 30.Pika 遇到问题 • 秒删 7 1 – 通过修改Rocksdb, 增加0version, 2 C timestamp 字段.删除只需要修改metadata C A S – 支持亿级别数据秒删
  • 31.Pika 遇到问题 • 数据compact – 修改Rocksdb manual compact 策略, 支持 7 1 0 低优先级的 manual compact 2 C – 根据机型调整rocksdb 配置, compac线程, C A S memtable 个数 – 晚上定期执行
  • 32.Pika 遇到问题 • 数据备份 – 需要rocksdb 和 Binlog 配合 2 C C A S 7 1 0
  • 33.Pika 运维 – 线上架构 LVS读写 VIP LVS只读 VIP 2 C C A S Master Slave 主机房A Slave Slave 机房B LVS读写 VIP 7 1 0 LVS读写 VIP Master Master Slave Slave 机房A 机房B
  • 34.Pika 运维 – 线上架构 LVS读写 VIP LVS只读 VIP 2 C C A S Master Slave1 主机房A Slave2 Slave3 机房B LVS读写 VIP LVS只读 VIP 7 1 0 Master 断点续传 Slave1 提 升为主库 主机房A Slave2 Slave3 机房B
  • 35.Pika 运维 – 迁移工具 – Redis_to_pika • 将redis数据迁移到pika，基于aof，能全量+增量方式同步数 据（Note关闭aof重写） 7 1 0 2 C • 业务增长过快，pika逐渐难以支持性能，将pika迁回redis， C 支持增量数据同步A S – Pika_to_redis – Ssdb_to_pika • 将ssdb数据迁移到pika，目前不支持增量同步
  • 36.Pika 运维 – 案例一 消息推送服务部分redis迁移到pika • 迁移前： 7 1 0 • 5套30G左右的redis主从，占用300G内存 2 C C A • 迁移后： S • SET数据结构为主 • 1套50G左右的pika主从，占用100多G磁盘
  • 37.Pika 运维 – 案例二 数据分析业务redis迁移到pika 迁移前： 7 1 业务数据量增长迅速，上线不到1周数据量增长 0 2 C 到40G C A S 迁移后： 1套100G+ Pika主从
  • 38.Pika 开发现状 • Pika团队目前有2个主力开发维护，2个DBA做需求分 析讨论、性能测试、bug跟踪、回归测试。积累1700+ 个测试用例 • 7 1 0 2 C 产品经理汇总github问题和交流群用户反馈,帮用户问 C A 题解决和需求排期开发 S • 一月一个小版本, 二月一个大版本
  • 39.Pika 开发现状 • 双主支持 7 1 0 • Pika_hub 提供多机房写入支持 • 支持sentinel • 支持codis 2 C C A S
  • 40.Pika 总结 • 恢复时间长 7 1 0 • 一主多从, 主从切换代价大 • 2 C 缓冲区写满问题 C A S • 内存昂贵问题
  • 41.Pika vs redis • 劣势 – 由于Pika是基于内存和文件来存放数据, 所以性能肯定比Redis 低一些 • 优势 – 容量大 – 加载db速度快 – 备份速度快 – 对网络容忍度高 – 性价比高 2 C C A S 7 1 0
  • 42.Pika vs redis -CPU:24 Cores, Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz –MEM:165157944 kB 7 1 0 2 C C –OS:CentOS release 6.2 (Final) A S – NETWORKCARD:Intel Corporation I350 Gigabit Network Connection
  • 43.Pika vs redis 2 C C A S 7 1 0
  • 44.Pika vs redis 2 C C A S 7 1 0
  • 45.Pika vs redis 来自vip 的测试 2 C C A Shttps://github.com/Qihoo360/pika7 1 0
  • 46.2 C C A S 7 1 0
  • 47.2 C C A S 7 1 0