《黄东旭-Codis 过去和未来-pingcap》由会员分享，可在线阅读，更多相关《黄东旭-Codis 过去和未来-pingcap（25页珍藏版）》请在金锄头文库上搜索。
1、Codis 过 去和未来黄东 旭 PingCAP关于我 PingCAP Cofounder & CTO MSRA / Netease / PingCAP 基础软 件工程师 / 架构师 / 开源狂热 分子 Codis TiDB TiKV Weibo: Dongxu_Huang Email: 2014 年. 重度 Redis 用户 大多数业务 的 cache 命中率要求 90% 以上，否则 DB 就不行了 数据量越来越大 独立的 Redis 实 例越来越多，业务 苦不堪言 Redis 一故障，基本业务 就不可用了 恢复时间 数据一致性 引入 TwemproxyRedis 为 什么那么快 绝 大部分
2、请 求是纯 粹的内存操作（非常快速） 采用单线 程,避免了不必要的上下文切换 和竞 争条件 非阻塞IO 内部实现 采用epoll，采用了epoll+自己实现 的简单 的事件框架。epoll中的读 、写、关闭 、连 接都转 化成了事件，然后利用epoll的多路复用特性，绝 不在io上浪费 一点时间 Twemproxy 最早/使用最广泛的解决方案 Proxy based 静态的拓扑 运维基本靠手 最大痛点：无法平滑的扩/缩容 甚至修改个配置都需要重启服务。 但是业务正在迅速的扩张一次 Twemproxy 扩 容引发 事故后。 下定决心彻 底解决的 Redis 的扩 展性问题 3 个人 1 个月Tw
3、emproxy 的问题 和优 点问题 ： 扩 容缩 容需要停服务 没有完善的监 控和运维 工具 不支持在线 的数据迁移 proxy 单线 程，无法利用好 CPU，只能靠多进 程优 点： state-less 的 proxy 模型，对业务 侵入小，proxy 层 能水平扩展 架构比较简单 ，升级 proxy 对 redis 的数据没影响Redis Cluster 官方出品 去中心化设计 ，类 raft 的算法 客户 端需要修改 (smart client) 整个系统 高度耦合，升级 比较 困难 Codis 完全兼容 Twemproxy 3 个人就写了俩 礼拜。就上线 了Codis 整体设计 Pr
4、e-sharding Slot = 0, 1023 Zookeeper Proxy 无状态 平滑扩 容/缩 容 扩 容对 用户 透明设计 考量 1/3 分布式系统 是复杂 的 开发 人员 不足 尽量拆分，简 化每个模块 ，同时 易于升级 每个组 件只负责 自己的事情 Redis 只作为 存储 引擎 Proxy 状态 设计 考量 2/3 Redis 是否挂掉的判定放到外部，因为 分布式系统 存活的判定是复杂 的 提供 API 让 外部调 用，当 Redis master 挂掉的时 候，提升 slave 为 master 我们 不喜欢读 写分离 基础软 件开发 者的自我修养。设计 考量 3/3 g
5、raph everything slot status proxy status group status lock actionproxy vs smart clientproxy：更好的监 控，控制后端信息不暴露，易于升级 smart client: 更好的性能更低的延迟 ，升级 比较 麻烦 无状态 Proxy1. 路由表统 一存储 在 Coordinator 中2. 连 接任意一个 proxy 发 起请 求的效果是一样 的3. 负载 均衡变 得非常简单 ，proxy 可以平滑的水平扩 展路由信息一致性保证 在 cluster-admin 发 起集群状态变 更时 ，所有的 proxy 必须
6、 达到信息的一致后，才能重新对 外提供服务 cluster-admin 和 proxy 之间 的二阶 段提交Codis 的设计 背景是要求强 一致的 宁可放弃部分可用性Codis 2.0+ Codis-HA 为 什么不做到自动 ？ Performance Pipeline 读 写分离 Stronger dashboard1. 平滑水平扩 展2. 可插拔的存储 引擎（ 各个模块 之间 的纽带 是 Redis Protocol ）3. 由于不同组 件之间 解耦, 都可以独立升级 a. proxyb. cluster adminc. storage engineResult我对 性能的一些看法 延迟
7、 ？吞吐？ Benchmark 的陷阱 需求和理想 性能是一切吗 ？基础软 件的未来 随着单 个计 算设备 物理成本的降低，集群化是必然的趋势 Scale-up vs Scale-out 最后必然的结 果：Cloud-native Infrastructure 真的会变 成水电 一样 自然的东 西基础软 件的未来 Application Container Scheduler Cahce DB OLTP OLAP DFS / Distributed Object StoreageGIFEE (Google Infrastructure For Everyone Else)最后做个小广告 :) Google Spanner / F1 的开源实现 A distributed SQL database that is widely used in Google The only OLTP database that works at scale 高度兼容 MySQL 事务 复杂查询 主从复制 运维 工具Thanks
