大容量redis存储方案--Pika 陈宗志 360基础架构组技术经理 SACC2017 简介 • 13年入职360 基础架构组 – Bada – Pika – Zeppelin – Mario, Pink, slash, floyd • https://github.com/Qihoo360 SACC2017 概要 • 存在问题 • 分析问题 • 解决问题 • Pika vs redis SACC2017 • Pika 是DBA 和 基础架构团队一起设计开发的 大容量redis的解决方案 • 完全兼容redis 协议, 用户不需要修改任何代码 进行迁移 Introduction SACC2017 • Redis实例数量：6000+个 • 日访问量：5000+亿 • Pika数据数量：1000+个 Pika 力求在完全兼容 Redis 协议、继承 Redis 便 捷运维设计的前提下通过持久化存储的方式解决 Redis 在大容量场景下的问题 Pika 定位 SACC2017 Redis 问题 • 恢复时间长 • 一主多从, 主从切换代价大 • 缓冲区写满问题 • 成本问题 SACC2017 Redis 问题 • 恢复时间长

跨区域部署就是 为了提高可用性 最后,我们使用"最终一 致性"来解决数据冲突 双向回 环 环形复 制 数据一 致性 网络模 型的选 择 双向/多向同步有哪些共同的问题 网络通讯的 模型选择 Redis A: • set k v Redis B: • set k v 发生在端对端的互相同步过程中 假设有两个 Redis: A 和 B • A 收到客户端的请求: set replication, 以达到节省流量和快速 同步的目的 Op-based Replication • 基于 unbounded resource 的假设上进行论证的学术理念, 在 实践过程中, 不可能有无限大的存储资源, 将某个站点的全部 数据缓存下来, 这样就带来一个问题, 如果新加节点或者网络 断开过久时, 我们的存储资源不足以缓存所有历史的操作, 从 而使得复制操作无法进行. 此时, 我们需要借助 State-based

的方式来清空整个内存。 rename 执行 rename oldkey newkey 时，如果 newkey 已经存在，redis 会先删除已经存在的 newkey，这也会引发 上面提到的删除大 key 问题。如果想让 redis 在这种场景下也使用 lazyfree 的方式来删除，您可以在控制台上 打开如下配置： 说明：该参数配置在控制台中暂未开放，后续我们会尽快发布。 硬件的功能，灵活多变的硬件选择，配合独特的 QoS模块，使综合硬件性价比达到最高。 产品优势 简单易用 完全兼容Redis协议，用户无需修改任何代码。 大容量 突破内存容量限制，单实例最高可支持TB级别的数据容量。 高性能 Redis混合存储型实例的绝大部分热点请求直接从内存获取，其性能与高性能内存型实例完 全一致。 型实例，内存中保留热门直播间的数据，不活跃的直播间数据被自动存储到磁盘上，可以达到对有限 内存的最佳利用效果。 电商类应用 电商类应用往往有大量的商品数据。使用Redis混合存储型实例，可以轻松突破内存容量限制，将大 量的商品数据都存储到Redis混合存储型实例中。在正常业务请求中，活跃的商品数据会留在内存中 ，而不活跃的商品数据会逐渐交换到磁盘上，可以免受内存不够的困扰。 产品系列

list的元素个数小于 8192, value 最大 长度不超过 1 MB。 Set 数据类型 没有 set 个数限制，单个元素最大值为 512 MB，推荐 set 的元素个数小于 8192， value 最 大长度不超过 1 MB。 Sorted set 数据类型 没有 sorted set 个数限制，单个元素最大值为 512 MB，推荐 sorted set 的元素个数小于 8192， value 最大长度不超过