codis_2.0_从分布式缓存到数据库.pdf

Codis 2.0：从Cache 到DB 黄东旭 关于我 ● 黄东旭 ● @ Dongxu_Huang ● Gopher ，脑残谷粉，分布式系统信徒，开 源运动实践者 Codis ● 分布式Redis ● Stateless Proxy-based ● 完全兼容Twemproxy ● 目前已经有很多知名和不知命的公司用于 生产环境 o 猎豹移动，科大讯飞，豌豆荚，汽车之家... ● 开源, github star 2200+ 传统单点缓存 Redis, Memcached 1. 单机内存有限 2. 带宽压力 3. 单点问题 4. 不能动态扩容 5. 磁盘损坏时数据抢救 分布式缓存 1. Twemproxy 2. Redis Cluster (official) 3. Tair, Coachbase, Aerospike 4. Codis Twemproxy 1. 最早/使用最广泛的解决方案 2. Proxy based 3. 静态的拓扑 4. 运维基本靠手 5. 最大痛点：无法平滑的扩/缩容 o 甚至修改个配置都需要重启服务Orz Redis Cluster 1. 官方出品 2. 去中心化设计 3. 客户端需要修改 4. 目前还缺乏Best Practice，还没有人写一个 Redis Cluster 若干条注意事项 5. 整个系统高度耦合，升级比较困难 Tair, Couchbase, Aerospike… 1. 技术选型 2. 数据结构支持 3. 社区 Codis 1.x Codis 1.x • 业务不停机，平滑扩/缩容 • 无状态Proxy，负载均衡，无单点 • 充分利用多核 • 运维工具齐全 – dashboard – redis-port – codis-ha Codis 1.x 缺点(maybe :P ) : • 强依赖zookeeper • 修改了官方redis • 性能 • MULTI / EXEC 等指令不支持 Codis 整体设计 ● Pre-sharding o Slot = [0, 1023] ● Zookeeper ● Proxy 无状态 ● 平滑扩容/缩容 ● 扩容对用户透明 设计考量 ● 分布式系统是复杂的 ● 开发人员不足 ● 尽量拆分，简化每个模块，同时易于升级 ● 每个组件只负责自己的事情 ● Redis 只作为存储引擎 ● Proxy 状态 设计考量 ● Redis 是否挂掉的判定放到外部，因为分布 式系统存活的判定是复杂的 ● 提供API 让外部调用，当Redis master 挂掉 的时候，提升slave 为master ● 我们不喜欢读写分离 设计考量 ● graph everything o slot status o proxy status o group status o lock o action 设计考量 proxy vs smart client proxy： 更好的监控，控制 后端信息不暴露，易于升级 smart client: 更好的性能 更低的延迟，升级比较麻烦 无状态Proxy 1. 路由表统一存储在Coordinator 中 2. 连接任意一个proxy 发起请求的效果是一 样的 3. 负载均衡变得非常简单，proxy 可以平滑的 水平扩展 路由信息一致性保证 • 在cluster-admin 发起集群状态变更时，所 有的proxy 必须达到信息的一致后，才能重 新对外提供服务 • cluster-admin 和proxy 之间通过二阶段提交 保证一致性 Read/Write Flow (Normal) Read/Write Flow (Migrating) 如何保证安全迁移 1. 将slot_X 状态标记为‘pre_migrate’ 2. 等待所有的proxy 确认 3. 将slot_X 状态标记为‘mig