美团点评技术沙龙010-redis cluster运维实践
Post on 12-Apr-2017
628 views
TRANSCRIPT
Redis Cluster 运维实践
卓汝林
主题
• Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
Redis Cluster简介
Replica(on + Sharding AP 16384 slots Resharding Smart Clients
Cluster Bus GossIP Heartbeats Auto Failover Config update
Smart client
集群示例
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)生产尝试使用
Redis Cluster的部分运维体系
• Redis监控和告警 • Redis数据备份还原 • Redis容量规划 • Redis运营数据平台
Redis监控和告警的价值
“无监控,不服务!” • Redis故障快速发现和定位故障点 • 分析Redis故障的Root cause • Redis容量规划和性能管理 • Redis资源利用率和成本管理
监控和告警-Open-Falcon Open-‐Falcon 是小米运维部开源的一款互联网企业级监控系统解决方案. 项目首页:hPp://open-‐falcon.com
使用公司:hPps://github.com/XiaoMi/open-‐falcon/issues/4
监控和告警-Open-Falcon Open-‐Falcon Redis指标采集-‐redismon 项目地址: hPps://github.com/ZhuoRoger/redismon 采集Redis监控指标100余项
Redis监控和告警 - Redismon for Open-Falcon
Redis监控和告警 - Redismon for Open-Falcon
Redis Cluster的部分运维体系
• Redis监控和告警 • Redis数据备份还原 • Redis容量规划 • Redis运营数据平台
Redis数据备份还原
• 基于Redis rdb的持久化备份,从库备份 redis-‐cli –rdb 远程备份 rdb文件传输网络出口IO fork的cow内存 模拟Slave的线程的客户端输出缓冲区 • Redis Cluster的还原推荐使用vipshop开源工具: hPps://github.com/vipshop/redis-‐migrate-‐tool
“无备份,不存储!”
Redis数据备份还原
Redis Cluster的部分运维体系
• Redis监控和告警 • Redis数据备份还原 • Redis容量规划 • Redis运营数据平台
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
Redis需求和容量评估申请表
业务名称 xxx-‐信息流广告
用途 控制xx计划展现
Redis服务不可用影响 用户可能看到同一xxx
Redis数据丢失影响 用户可能看到同一xxx
数 据 类 型(String,List,Set等)
String
预估最大数量 800W
key标准前缀 xx:120:
所有key过期时间 一天
预估最大单位容量(内存MB)
2G
预估最大峰值(每秒读写)
1k
预估最大连接数
Redis容量规划-内存
Redis运营数据平台
Redis运营数据平台
主题
• Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
Redis 故障排查常见案例
• Redis 单线程和排队理论 • 服务响应变慢,但Redis无任何慢查询 • 复制中断和无限同步 • 主从数据不一致 • 数据丢失问题 • Redis的”死键”问题 • Redis集群“倾斜”问题 more
Redis单线程和排队理论
Redis 单线程:同一时间只能处理一个命令,并且是同步完成的,不会yield 排队理论:一个请求耗时= 请求排队的时间 + 请求被服务的时间 redis slowlog: 只计CPU耗时,不计算排队或IO等待时间
服务响应变慢,但Redis无明显慢查询
性能故障: 服务访问Redis 99th响应时间>50ms, 但redis 1ms慢查询slow_len=0。 原因: 因资源饱和或某类慢请求,引起整体排队拥塞,每个请求耗时增长; 监测: 1 监控Redis端口响应时间:抽样分析Redis TCP包耗时(注意观察者效应) 2 各个子系统的饱和度监控 故障常见场景: 1 Redis 进程所占用CPU饱和(per-‐cpu idle), 导致整体耗时变慢(积压队列) 2 Redis服务器网络进出口过载,成为瓶颈 3 某类慢请求,引起整体排队 4 某个大命令阻塞秒级,导致所有请求排队
复制中断和无限同步 理论: • 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"
复制中断和无限同步
故障表现: • 因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
主从数据不一致
• Redis过期key量大,hz频率的清理不及时 ,内存消耗过大。主库KEY会比从库多
• 从库KEY个数多;从库达到maxmemory设置,数据写入操作不能同步
• 从库Reay_only未设置 • 从库读取到已过期的”死键” • 同步延时
数据丢失
• query buffer不受maxmeory限制的BUG, 导致缓存完全丢失 • cmdstat_FlushALL / cmdstat_FlushDB • cmdstat_DEL • evicted_keys • expired_keys • Master未设置持久化,重启后未发生Failover导致Slave被Flush • 网络分区问题导致少量写入数据丢失
Redis 故障排查常见案例
• Redis的”死键”问题 • Redis集群“倾斜”问题
主题
• Redis Cluster简介 • Redis Cluster的部分运维体系 • Redis 故障排查常见案例 • Redis大规模集群运维遇到的问题 • 针对这些问题的解决方案
Redis大规模集群运维遇到的问题
• 资源调度与管理复杂,资源利用率不高 • 单机多业务多实例部署,⽆无资源隔离,实例间相互影响 • 不能快速的弹性扩容和缩容集群 • 针对⼤大容量KV存储,成本⾼高 • Redis的数据存储,⽆无法保证不丢数据,尤其是脏写 • Redis集群的过载保护不完善 • 跨IDC的⾼高可⽤用
针对这些问题的解决方案和规划
• 基于mesos+marathon+docker的DBass解决⽅方案 • 基于MySQL Replication的kv存储系统介绍 • 基于SSD的KV存储⽅方案
DBass 之redis • 资源服务化,产品化,标准化
• 快速交付 �• 资源计费(规划) �
• 提高资源利用率 • 实现IDC资源统一调度,无需为单一业务预留 buffer ,提升资源利用率 �
• 单机多实例部署,资源隔离 • 使用docker,部署实例,实现资源隔离 �
• 快速扩容,快速缩容 • 利用mesos的动态资源管理功能,封装redis cluster管理工具实现动态扩容 �
• 高可用 • Cluster 自动failover �• 从实例挂掉,自动重建一个从实例 �• 主实例挂掉,秒级完成切换 �• 自动保持实例数不变 �
Mesos架构
Marahton
集群demo
社交分布式kv存储系统
• GET/GETALL/SET/DEL接口 • 适合高QPS ,数据量~G(<1T)数量级 • 底层存储基于MYSQL/REDIS
社交存储系统
• 高性能 • 基于SSD的MYSQL服务 + MEMORY的REDIS服务 • 接入层 QPS ~6万/秒
• 高可用 • REDIS故障1分钟内自动切换 • 访问MYSQL使用VIP 自动识别VIP切换
• 平滑扩容/缩容 • 对业务完全透明,操作期间无任何副作用 • 一键操作 • 支持任务管理(状态和进度查询及异常中断恢复)
基于SSD的KV存储⽅方案 • 小米存储团队分布式kv存储 • 360开源的pika
谢谢!