美团点评技术沙龙010-Redis Cluster运维实践
•
1 gostou•2,082 visualizações
介绍Redis Cluster在小米的运营体系，Redis常见问题和Trouble shooting; Redis Cluster的容量规划；目前大规模集群面临的问题，以及正在规划的Redis基于Docker容器运维管理。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a 美团点评技术沙龙010-Redis Cluster运维实践
Semelhante a 美团点评技术沙龙010-Redis Cluster运维实践 (20)
Mais de 美团点评技术团队
Mais de 美团点评技术团队 (11)
美团点评技术沙龙010-Redis Cluster运维实践
- 2. 主题 • Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
- 3. Redis Cluster简介 Replica(on + Sharding AP 16384 slots Resharding Smart Clients Cluster Bus GossIP Heartbeats Auto Failover Config update Smart client
- 4. 集群示例
- 5. Redis Cluster的运维现状 Redis Cluster 3.0版本，新集群3.2版本(测试) 目前百余集群，数千节点；缓存和存储 单个集群内存容量1TB+，15亿+的键，百万级QPS吞吐量 Redis Cluster发布历史 3.0Beta1 (2014.2)-‐-‐-‐3.0.0 rc(2014.10)-‐-‐-‐3.0GA(2015.4)—3.2(2016.5). 我们从3.0 beta7 (2014.6)生产尝试使用
- 8. 监控和告警-Open-Falcon Open-‐Falcon 是小米运维部开源的一款互联网企业级监控系统解决方案. 项目首页：hPp://open-‐falcon.com 使用公司：hPps://github.com/XiaoMi/open-‐falcon/issues/4
- 9. 监控和告警-Open-Falcon Open-‐Falcon Redis指标采集-‐redismon 项目地址: hPps://github.com/ZhuoRoger/redismon 采集Redis监控指标100余项
- 10. Redis监控和告警 - Redismon for Open-Falcon
- 11. Redis监控和告警 - Redismon for Open-Falcon
- 13. Redis数据备份还原 • 基于Redis rdb的持久化备份，从库备份 redis-‐cli –rdb 远程备份 rdb文件传输网络出口IO fork的cow内存 模拟Slave的线程的客户端输出缓冲区 • Redis Cluster的还原推荐使用vipshop开源工具： hPps://github.com/vipshop/redis-‐migrate-‐tool “无备份,不存储!”
- 14. Redis数据备份还原
- 16. Redis容量规划 Redis容量规划考虑角度 • Redis单实例 • 性能 • maxmemory设置多大 • 键个数多少 • QPS上限？ TCPS更靠谱？业务访问模式 • 连接数个数 • fork time (used_memory_rss) • rdb load time • 每秒写入网络IO流量，大于80MB及有可能导致复 制中断 • 过期键回收速度(hz默认10，回收几十个每秒) • 缓存命中率？未命中次数？ • Redis集群(large or small?) • 集群多少个分片/节点合适 • cluster failover time • Cluster gossip network traffic • cluster slots traffic • Redis内存资源 • maxmemory写入失败 • 工作集数据容量>>memory? • OOM killer • COW(double) • 客户端输入/输出缓冲区 • 复制积压缓冲区 • 内部或外部碎片 • Redis CPU资源 • single-thread on per core • fork on more cores • fork speed(Intel E2630V2 0.7ms/GB) • rdb compress/load speed • Redis网络流量(万兆！！！) • 网络出口流量 • pipeline • Redis Disk • AOF fsync(latency) • swap
- 17. Redis需求和容量评估申请表 业务名称 xxx-‐信息流广告 用途 控制xx计划展现 Redis服务不可用影响 用 户 可 能 看 到 同 一 xxx Redis数据丢失影响 用 户 可 能 看 到 同 一 xxx 数 据 类 型 （String,List,Set等) String 预估最大数量 800W key标准前缀 xx:120： 所有key过期时间 一天 预估最大单位容量（内 存MB) 2G 预估最大峰值(每秒读 写） 1k 预估最大连接数 Redis容量规划-内存
- 18. Redis运营数据平台
- 19. Redis运营数据平台
- 20. 主题 • Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
- 21. Redis 故障排查常见案例 • Redis 单线程和排队理论 • 服务响应变慢，但Redis无任何慢查询 • 复制中断和无限同步 • 主从数据不一致 • 数据丢失问题 • Redis的”死键”问题 • Redis集群“倾斜”问题 more
- 22. Redis单线程和排队理论 Redis 单线程：同一时间只能处理一个命令，并且是同步完成的，不会yield 排队理论：一个请求耗时= 请求排队的时间 + 请求被服务的时间 redis slowlog: 只计CPU耗时，不计算排队或IO等待时间
- 23. 服务响应变慢，但Redis无明显慢查询 性能故障: 服务访问Redis 99th响应时间>50ms, 但redis 1ms慢查询slow_len=0。 原因： 因资源饱和或某类慢请求，引起整体排队拥塞，每个请求耗时增长； 监测： 1 监控Redis端口响应时间：抽样分析Redis TCP包耗时（注意观察者效应） 2 各个子系统的饱和度监控 故障常见场景： 1 Redis 进程所占用CPU饱和(per-‐cpu idle), 导致整体耗时变慢(积压队列） 2 Redis服务器网络进出口过载，成为瓶颈 3 某类慢请求，引起整体排队 4 某个大命令阻塞秒级，导致所有请求排队
- 24. 复制中断和无限同步 理论: • Client Output buffer: 执行命令所返回的结果会保存到output buffer，返回给客户端。 Slave复制客户端Client output buffer超过 “client-‐output-‐buffer-‐limit“ slave的hard limit 或soh limit slave 2684354560 67108864 600 • Master、Slave库相互心跳, 超过repl-‐imeout秒数限制会断开复制线程 Master的角度: slave每秒向master发送REPLCONF ACK检测试同步,超时会后，master会主动断开复制 Slave的角度: -‐ master在repl-‐imeout秒没有发送ping -‐ sync过程中，slave在repl-‐imeout秒没有收到master的RDB文件 1469733101.552631 [0 127.0.0.1:7000] "PING" 1469733111.563652 [0 127.0.0.1:7000] "PING" 1469733070.851227 [0 127.0.0.1:60163] "REPLCONF" "ACK" "43" 1469733071.852618 [0 127.0.0.1:60163] "REPLCONF" "ACK" "57" 1469733072.853909 [0 127.0.0.1:60163] "REPLCONF" "ACK" "57"
- 25. 复制中断和无限同步 故障表现： • 因Client Output buffer达到限制，Master主动断开 • Slave未及时上报超时，Master断开复制 [29129] 29 Jul 03:16:05.910 # Disconnecting timedout slave: 127.0.0.1:7001 [29129] 29 Jul 03:16:05.910 # Connection with slave 127.0.0.1:7001 lost. [29129] 29 Jul 03:16:06.148 * Slave asks for synchronization [29129] 29 Jul 03:16:06.148 * Partial resynchronization request accepted. Sending 84 bytes of backlog starting from offset 380. • Master未及时ping，Slave断开复制 [30100] 29 Jul 03:34:24.625 # MASTER timeout: no data nor PING received... [30100] 29 Jul 03:34:24.625 # Connection with master lost. [30100] 29 Jul 03:34:24.625 * Caching the disconnected master state. [30100] 29 Jul 03:34:24.625 * Connecting to MASTER 127.0.0.1:7000 [30100] 29 Jul 03:34:24.625 * MASTER <-> SLAVE sync started
- 26. 主从数据不一致 • Redis过期key量大，hz频率的清理不及时 ，内存消耗过大。主库 KEY会比从库多 • 从库KEY个数多；从库达到maxmemory设置，数据写入操作不能同 步 • 从库Reay_only未设置 • 从库读取到已过期的”死键” • 同步延时
- 27. 数据丢失 • query buffer不受maxmeory限制的BUG, 导致缓存完全丢失 • cmdstat_FlushALL / cmdstat_FlushDB • cmdstat_DEL • evicted_keys • expired_keys • Master未设置持久化，重启后未发生Failover导致Slave被Flush • 网络分区问题导致少量写入数据丢失
- 28. Redis 故障排查常见案例 • Redis的”死键”问题 • Redis集群“倾斜”问题
- 29. 主题 • Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
- 30. Redis大规模集群运维遇到的问题 • 资源调度与管理复杂，资源利用率不高 • 单机多业务多实例部署，⽆无资源隔离，实例间相互影响 • 不能快速的弹性扩容和缩容集群 • 针对⼤大容量KV存储，成本⾼高 • Redis的数据存储，⽆无法保证不丢数据，尤其是脏写 • Redis集群的过载保护不完善 • 跨IDC的⾼高可⽤用
- 31. 针对这些问题的解决方案和规划 • 基于mesos+marathon+docker的DBass解决⽅方案 • 基于MySQL Replication的kv存储系统介绍 • 基于SSD的KV存储⽅方案
- 32. DBass 之redis • 资源服务化，产品化，标准化 • 快速交付 • 资源计费（规划） • 提高资源利用率 • 实现IDC资源统一调度,无需为单一业务预留 buffer ,提升资源利用率 • 单机多实例部署，资源隔离 • 使用docker，部署实例，实现资源隔离 • 快速扩容，快速缩容 • 利用mesos的动态资源管理功能，封装redis cluster管理工具实现动态扩容 • 高可用 • Cluster 自动failover • 从实例挂掉，自动重建一个从实例 • 主实例挂掉，秒级完成切换 • 自动保持实例数不变
- 33. Mesos架构
- 34. Marahton
- 35. 集群demo
- 36. 社交分布式kv存储系统 • GET/GETALL/SET/DEL接口 • 适合高QPS ,数据量~G(<1T)数量级 • 底层存储基于MYSQL/REDIS
- 37. 社交存储系统 • 高性能 • 基于SSD的MYSQL服务 + MEMORY的REDIS服务 • 接入层 QPS ~6万/秒 • 高可用 • REDIS故障1分钟内自动切换 • 访问MYSQL使用VIP 自动识别VIP切换 • 平滑扩容/缩容 • 对业务完全透明,操作期间无任何副作用 • 一键操作 • 支持任务管理(状态和进度查询及异常中断恢复)
- 38. 基于SSD的KV存储⽅方案 • 小米存储团队分布式kv存储 • 360开源的pika
- 39. 谢谢！