360基础架构组技术经理 陈宗志：大容量redis存储方案--Pika
2020-02-27 421浏览
- 1.大容量reSdAi陈sC存宗C储志20方17案--Pika 360基础架构组技术经理
- 2.简介 • 13年入职360 基础架构组 – Bada – Pika – Zeppelin SACC2017 – Mario, Pink, slash, floyd •https://github.com/Qihoo360
- 3.概要 • 存在问题 • 分析问题 • 解决问题 SACC2017 • Pika vs redis
- 4.Introduction • Pika 是DBA 和 基础架构团队一起设计开发的 • 进完大行全容迁兼量移容redreisd的is解S协决A议方C, 用案C户2不01需7要修改任何代码
- 5.Pika User • Redis实例数量：6000+个 • 日访问量：5000+亿 • • P日ik访a数问据量数：量10：001S+0A亿00C+个C2017 • 覆盖率：80%以上业务线 • 单份数据体积：6.8T
- 6.SACC2017
- 7.Pika 定位 Pika 的出现并不是为了替代 Redis，而是 Redis 的场景补充。 P捷ik运a维力设求计在的完前全提兼S下容A通CR过eCd持i2s久0协化1议7存、储继的承方R式ed解is决便 Redis 在大容量场景下的问题
- 8.Redis 问题 • 恢复时间长 • • • 缓成一冲本主区问多写题从满, 主问从题S切A换C代C价2大017
- 9.Redis 问题 • 恢–– 5同复0时时G开r间e启d长iaso回Sf 复和A时Crd间Cb7200分1钟7
- 10.Redis 问题 • 一– 据主主库多挂从掉, 后主升S从A级切C从换C库代2, 所0价有1大7的从库全部重传数
- 11.Redis 问题 • 缓–– 内网冲存络区是原写昂因满贵很问资容S题A源易C将, 缓C数冲2据区0堵一1死7般, 设那置么2就G会发生大 量数据重传
- 12.Redis 问题 • 内存太贵 SACC2017– 线上使用的redis 机器是 64G, 96G. 只使用 80% 的空间. – 如果一个redis 的实例是50G, 那么基本一台 机器只能运行一个redis 实例. 特别的浪费资 源
- 13.Redis 问题 90/GB VS 2.6/GB SACC201370倍的差距
- 14.问题分析 • 成本问题 • • 可用性问题 同步问题 SACC2017 • 易用性问题
- 15.问题分析 • 尽可能兼容redis 协议 • • 网使数据络用库基接于口接磁盘口S的A存CC储2引0擎17rocksdb 实现多 • 添加binlog 模块
- 16.Pika 整体结构 SACC2017
- 17.网络模块--Pink • 基础架构团队开发网络编程库, 支持pb, redis, pg, http等协议. • 抽象各种不同类型线程 17– DispatchThread C20– WorkThread SAC– BGThread •https://github.com/Qihoo360/pink
- 18.网络模块--Pink • 稳定行, 在各个项目中使用4年多 • 易用性 • 高性能 SACC2017
- 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
- 20.网络模块--Pink SACC2017
- 21.存储引擎--Nemo • Nemo – Pika 的存储引擎, 基于Rocksdb 实现. 实现了Hash, 7List, Set, Zset 等数据结构 201– Rocksdb 启动只需要加载log 文件 SACC– Rocksdb 使用的本地硬盘, 对SSD 盘友好 –https://github.com/Qihoo360/nemo
- 22.存储引擎--Nemo SACC2017
- 23.存储引擎--Nemo • HSET myhash field1 "Hello" 017– DB->Put(wop, h6myhashfield1,Hello01477671118) SACC2– DB->Put(wop, Hmyhash11477671118, 6)
- 24.存储引擎--Nemo SACC2017
- 25.存储引擎--Nemo • LPUSH mylist "world" 017– DB->Put(wop, l6mylist6, 57world01477671118) SACC2– DB->Put(wop, Lmyhash11477671118, 6071)
- 26.日志模块--Binlog • Binlog – – 顺检解序查决写了文缓件冲,区S通小A过的CIn问dC题e2x 0+1o7ffset 进行同步点 – 支持全同步 + 增量同步
- 27.日志模块--Binlog SACC2017
- 28.主从同步-- slaveof SACC2017
- 29.主从同步-- slaveof SACC2017
- 30.Pika 遇到问题 • 秒删 – 通tim过e修sta改mRpoc字Sks段Ad.bC删, C增除2加只0需v1e要7rs修io改n,metadata – 支持亿级别数据秒删
- 31.Pika 遇到问题 • 数据compact – 修改Rocksdb manual compact 策略, 支持 – 根低据优机先型级调的整mSraoAncuCkasCdl cb2o配0m1置p7a,cctompac线程, memtable 个数 – 晚上定期执行
- 32.Pika 遇到问题 • 数据备份 2017– 需要rocksdb 和 SACCBinlog 配合
- 33.Pika 运维 – 线上架构 LVS读写 VIP Master Slave 主机房A LVS只读 VIP LVS读写 VIP SACC2017Master Slave Slave 机房B Slave 机房A LVS读写 VIP Master Slave 机房B
- 34.Pika 运维 – 线上架构 LVS读写 VIP Master Slave1 主机房A LVS只读 VIP LVS读写 VIP LVS只读 VIP SACC2017Master 断点续传 Slave2 Slave3 机房B Slave1 提 升为主库 主机房A Slave2 Slave3 机房B
- 35.Pika 运维 – 迁移工具 – Redis_to_pika • 将redis数据迁移到pika，基于aof，能全量+增量方式同步数 据（Note关闭aof重写） 17– Pika_to_redis C20• 业务增长过快，pika逐渐难以支持性能，将pika迁回redis， SAC支持增量数据同步 – Ssdb_to_pika • 将ssdb数据迁移到pika，目前不支持增量同步
- 36.Pika 运维 – 案例一 消息推送服务部分redis迁移到pika • 迁移前： • SET数据结构为主 2017• 5套30G左右的redis主从，占用300G内存 SACC• 迁移后： • 1套50G左右的pika主从，占用100多G磁盘
- 37.Pika 运维 – 案例二 数据分析业务redis迁移到pika 迁移前： 17业务数据量增长迅速，上线不到1周数据量增长 C20到40G SAC迁移后： 1套100G+ Pika主从
- 38.Pika 开发现状 • Pika团队目前有2个主力开发维护，2个DBA做需求分 析讨论、性能测试、bug跟踪、回归测试。积累1700+ 17个测试用例 C20• 产品经理汇总github问题和交流群用户反馈,帮用户问 SAC题解决和需求排期开发 • 一月一个小版本, 二月一个大版本
- 39.Pika 开发现状 • 双主支持 • • 支Pik持a_shenutbin提el供多SA机房C写C入20支1持7 • 支持codis
- 40.Pika 总结 • 恢复时间长 • • 缓一冲主区多写从,满主问从题切S换A代C价C大2017 • 内存昂贵问题
- 41.Pika vs redis • 劣势 – 由于Pika是基于内存和文件来存放数据, 所以性能肯定比Redis 低一些 • 优势 – 容量大 – 加载db速度快 – 备份速度快 SACC2017 – 对网络容忍度高 – 性价比高
- 42.Pika vs redis -CPU:24 Cores, Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz – –MOSE:MCe:n1t6O5S15re7Sl9e4aA4seCkB6C.2 2(F0ina1l)7 – NETWORKCARD:Intel Corporation I350 Gigabit Network Connection
- 43.Pika vs redis SACC2017
- 44.Pika vs redis SACC2017
- 45.Pika vs redis 来自vip 的测试 SACC2017https://github.com/Qihoo360/pika
- 46.SACC2017
- 47.SACC2017
