codis 2从分布式缓存到数据库.pptx

Codis 2.0：从 Cache 到 DBCodis ● 分布式 Redis ● Stateless Proxy-based ● 完全兼容 Twemproxy ● 目前已经有很多知名和不知命的公司用于 生产环境猎豹移动，科大讯飞，豌豆荚，汽车之家...o● 开源, github star 2200+传统单点缓存Redis, Memcached1. 单机内存有限2. 带宽压力3. 单点问题4. 不能动态扩容5. 磁盘损坏时数据抢救分布式缓存1. Twemproxy2. Redis Cluster (official)3. Tair, Coachbase, Aerospike4. CodisTwemproxy 1. 最早/使用最广泛的解决方案 2. Proxy based 3. 静态的拓扑 4. 运维基本靠手 5. 最大痛点：无法平滑的扩/缩容甚至修改个配置都需要重启服务 OrzoRedis Cluster1. 官方出品2. 去中心化设计3. 客户端需要修改4. 目前还缺乏 Best Practice，还没有人写一个Redis Cluster 若干条注意事项5. 整个系统高度耦合，升级比较困难Tair, Couchbase, Aerospike…1. 技术选型2. 数据结构支持3. 社区Codis 1.xCodis 1.x???? 业务不停机，平滑扩/缩容 无状态 Proxy，负载均衡，无单点 充分利用多核 运维工具齐全– dashboard– redis-port– codis-haCodis 1.x缺点(maybe :P ) :? 强依赖 zookeeper? 修改了官方 redis? 性能? MULTI / EXEC 等指令不支持Codis 整体设计 ● Pre-shardingSlot = [0, 1023]o●●●●ZookeeperProxy 无状态平滑扩容/缩容扩容对用户透明设计考量●●●●●●分布式系统是复杂的开发人员不足尽量拆分，简化每个模块，同时易于升级每个组件只负责自己的事情Redis 只作为存储引擎Proxy 状态设计考量● Redis 是否挂掉的判定放到外部，因为分布式系统存活的判定是复杂的● 提供 API 让外部调用，当 Redis master 挂掉的时候，提升 slave 为 master● 我们不喜欢读写分离设计考量 ● graph everythingslot statusproxy statusgroup statuslockactionooooo设计考量proxy vs smart clientproxy：更好的监控，控制后端信息不暴露，易于升级smart client: 更好的性能更低的延迟，升级比较麻烦无状态 Proxy1. 路由表统一存储在 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 状态标记为‘migrating’4. admin 不断发送 SLOTSMGRT 命令给 source redis instance 直到 slot_X 所有的 key 迁移完成5. 将 slot_X 状态标记为 ‘online’Result 1. 平滑水平扩展 2. 可插拔的存储引擎（ 各个模块之间的纽带 是 Redis Protocol ） 3. 由于不同组件之间解耦, 都可以独立升级proxya.b. cluster adminc. storage engineRebornDBRebornDB (Codis 2.0)1. Support both zookeeper and etcd2. Plugglable storage engine3. Backend pipeline4. Simple HA tools5. New Dashboard6. Sync Replication7. Distributed Redis Protocol Framework性能Intel(R) Core(TM) i7-4770 CPU @ 3.40GHzredis-benchmark-p 22121 -c 500 -n 5000000 -P 100 -r 10000 -t get,