一、集群-主从复制
你的redis是否高可用?
- 单机redis的风险与问题
- 问题1.机器故障
- 现象:硬盘故障、系统崩溃
- 本质:数据丢失,很可能对业务造成灾难性打击
- 结论:基本上会放弃使用redis
- 问题2.容量瓶颈
- 现象:内存不足,从16G升级到64G,从64G升级到128G,无限升级内存
- 本质:穷,硬件条件跟不上
- 结论:放弃使用redis
- 结论:为了避免单点Redis服务器故障,准备多台服务器,互相连通。将数据复制多个副本保存在不同的服 务器上,连接在一起,并保证数据是同步的。即使有其中一台服务器宕机,其他服务器依然可以继续 提供服务,实现Redis的高可用,同时实现数据冗余备份
1、多台服务器连接方案
- 提供数据方:master
- 主服务器,主节点,主库
- 主客户端
- 接收数据方:slave
- 从服务器,从节点,从库
- 从客户端
- 需要解决的问题:
- 数据同步
- 核心工作:
- master的数据复制到slave中(主计算机向从计算机复制数据)
2、主从复制
- 主从复制即将master中的数据即时,有效的复制到slave中
- 特征:一个master可以拥有多个slave,一个slave只对应一个master
- 职责:
- master:
- 写数据
- 执行写操作时,将出现变化的数据自动同步到slave
- 读数据(可忽略)
- slave:
- 读数据
- 写数据(禁止写,因为不会同步出去)
- master:
3、高可用集群方案:
- 如果master主机宕机了,那么直接挑选一个从机做主机
- 如果slave宕机了,那么还有别的slave工作,不慌
4、主从复制的作用
- 读写分离:master写,slave读,提高服务器的读写负载能力.
- 负载均衡:基于主从结构,配合读写分离,由slave分担master负载,并根据需求的变化,改变slave的数量,通过多个节点分担数据读取负载,大大提高了redis服务器并发量与数据吞吐量
- 故障恢复:当master出现问题时,由slave提供服务,实现快速的故障恢复
- 数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式。
- 高可用基石:基于主从复制,构建哨兵模式与集群,实现redis的高可用方案
5、主从复制的工作流程
主从复制大体可以分为3个阶段:
- 建立连接阶段(即准备阶段)
- 建立同步阶段
- 命令传播阶段
① 阶段1:连接阶段
主从连接
- 方式1:客户端发送命令(从机发送)
**slaveof **``主机``ip ``主机``port
- 方式2:启动服务器参数(从机启动时)
**redis-server -slaveof **``主机``ip ``主机``port
- 方式3:服务器配置(从机配置 主流方式)
**slaveof **``主机``if ``主机``port
- 当连接上之后 主机set key value 从机get key 就可以得到
- 主机的端口号是6379 从机的端口号是6380 必须区分开
- 在使用redis-cli 时 加上 -p 端口号
断开连接
- 客户端发送指令(从机发送)
**slaveof no one **
- 说明:从机断开后,不会删除从机上的所有数据,而是不再接收master发送的数据了
② 阶段2:数据同步阶段
在slave初次连接master后,复制master中的所有数据到slave 将slave的数据库状态更新成master当前的数据库状态
数据同步流程
- 从机向主机发送 psync2 指令,请求同步数据
- 主机使用bgsave创建RDB文件 同步数据
- 从机使用主机给的RDB文件 恢复数据(恢复之前把以前的数据都清空)
- 发送指令告知RDB已经恢复完成
- 从机请求部分同步数据
- 主机向从机发送 数据指令 AOF
- 从机接收到使用 bgrewriteaof 恢复数据
状态:
- slave:具有master端全部数据,包含RDB过程接收的数据
- master:保存slave当前数据同步的位置
- 总体:之间完成了数据克隆
数据同步阶段master说明:**
- 如果master数据量巨大,数据同步阶段应避开流量高峰期,避免造成master阻塞,影响业务正常执行。
- 复制缓冲区大小设定不合理,会导致数据溢出,如果进行全量复制周期太长,进行部分复制时发现数据已经存在丢失的情况,必须进行第二次全量复制,致使slave陷入死循环状态
- 修改master复制缓冲区 [配置文件]: repl-backlog-size 1mb
- master单击内存占用主机内存的比例不应过大,建议使用50%-70%的内存,留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区。
数据同步阶段slave说明:
- 为了避免slave进行全量复制,部分复制时服务器响应阻塞或数据不同步,建议关闭此期间的对外服务。
- slave只对外提供读取操作(关闭set操作配置文件): slave-serve-stale-data yes|no
- 数据同步阶段,master发送给slave信息可以理解master时slave的一个客户端,主动向slave发送命令。
- 多个slave同时对master请求数据同步,master发送的RDB文件增多,会对宽带造成巨大冲击,如果master带宽不足,因此数据同步需要根据业务需求,适量错峰。
slave过多时,建议调整拓扑结构,由一主多从结构变为树状结构,中间的节点既是master,也是 slave。注意使用树状结构时,由于层级深度,导致深度越高的slave与最顶层master间数据同步延迟 较大,数据一致性变差,应谨慎选择
③ 阶段3:命令传播阶段
当master数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的 状态,同步的动作称为命令传播
- master将接收到的数据变更命令发送给slave,slave接收命令后执行命令
- 主从复制过程大体可以分为3个阶段
- 建立连接阶段(即准备阶段)
- 数据同步阶段
- 命令传播阶段
命令传播阶段的部分复制
服务器运行id(主机识别从机身份,如果和之前的不一样那么说明从机的数据和主机数据不一致)
- 概念:服务器运行ID是每一台服务器每次运行的身份识别码,一台服务器多次运行可以生成多个运行id
- 组成:运行id由40位字符组成,是一个随机的十六进制字符 例如:fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
- 作用:运行id被用于在服务器间进行传输,识别身份 如果想两次操作均对同一台服务器进行,必须每次操作携带对应的运行id,用于对方识别
实现方式:运行id在每台服务器启动时自动生成的,master在首次连接slave时,会将自己的运行ID发 送给slave,slave保存此ID,通过info Server命令,可以查看节点的runid
3.2 复制缓冲区
概念:复制缓冲区,又名复制积压缓冲区,是一个先进先出(FIFO)的队列,用于存储服务器执行过的命 令,每次传播命令,master都会将传播的命令记录下来,并存储在复制缓冲区
- 复制缓冲区默认数据存储空间大小是1M,由于存储空间大小是固定的,当入队元素的数量大于队 列长度时,最先入队的元素会被弹出,而新元素会被放入队列
- 由来:每台服务器启动时,如果开启有AOF或被连接成为master节点,即创建复制缓冲区
- 作用:用于保存master收到的所有指令(仅影响数据变更的指令,例如set,select)
数据来源:当master接收到主客户端的指令时,除了将指令执行,会将该指令存储到缓冲区中
3.3 主从服务器复制偏移量(offset)
概念:一个数字,描述复制缓冲区中的指令字节位置
- 分类:
- master复制偏移量:记录发送给所有slave的指令字节对应的位置(多个)
- slave复制偏移量:记录slave接收master发送过来的指令字节对应的位置(一个)
- 数据来源:
- master端:发送一次记录一次
- slave端:接收一次记录一次
作用:同步信息,比对master与slave的差异,当slave断线后,恢复数据使用
3.4 数据同步+命令传播阶段流程
4、心跳机制
进入命令传播阶段候,master与slave间需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线
- master心跳:
- 指令:PING
- 周期:由repl-ping-slave-period决定,默认10秒
- 作用:判断slave是否在线
- 查询:INFO replication 获取slave最后一次连接时间间隔,lag项维持在0或1视为正常
slave心跳任务:
6、全量复制常见问题:
频繁的全量复制(1)
- 伴随着系统的运行,master的数据量会越来越大,一旦master重启,runid将发生变化,会导致全部slave的 全量复制操作
- 内部优化调整方案:
- master内部创建master_replid变量,使用runid相同的策略生成,长度41位,并发送给所有slave
- 在master关闭时执行命令 shutdown save,进行RDB持久化,将runid与offset保存到RDB文件中
repl-id repl-offset
- 通过redis-check-rdb命令可以查看该信息
- master重启后加载RDB文件,恢复数据
- 重启后,将RDB文件中保存的repl-id与repl-offset加载到内存中
master_repl_id = repl master_repl_offset = repl-offset
- 通过info命令可以查看该信息
- 作用:
- 本机保存上次runid,重启后恢复该值,使所有slave认为还是之前的master
频繁的全量复制(2)
- 问题现象
- 网络环境不佳,出现网络中断,slave不提供服务
- 问题原因
- 复制缓冲区过小,断网后slave的offset越界,触发全量复制
- 最终结果
- slave反复进行全量复制
- 解决方案
- 修改复制缓冲区大小
**repl-backlog-size**
- 修改复制缓冲区大小
- 建议设置如下:
- 测算从master到slave的重连平均时长second
- 获取master平均每秒产生写命令数据总量write_size_per_second
- 最优复制缓冲区空间 = 2 second write_size_per_second
频繁的网络中断(1)
- 问题现象
- master的CPU占用过高或 slave频繁断开连接
- 问题原因
- slave每1秒发送REPLCONF ACK命令到master
- 当slave接到了慢查询时(keys * ,hgetall等),会大量占用CPU性能
- master每1秒调用复制定时函数replicationCron(),比对slave发现长时间没有进行响应
- 最终结果
- master各种资源(输出缓冲区、带宽、连接等)被严重占用
- 解决方案
- 通过设置合理的超时时间,确认是否释放slave
**repl-timeout**
- 该参数定义了超时时间的阈值(默认60秒),超过该值,释放slav
- 通过设置合理的超时时间,确认是否释放slave
频繁的网络中断(2)
- 问题现象
- slave与master连接断开
- 问题原因
- master发送ping指令频度较低
- master设定超时时间较短
- ping指令在网络中存在丢包
- 解决方案
- 提高ping指令发送的频度
**repl-ping-slave-period**
- 超时时间repl-time的时间至少是ping指令频度的5到10倍,否则slave很容易判定超时
- 提高ping指令发送的频度
数据不一致
- 问题现象
- 多个slave获取相同数据不同步
- 问题原因
- 网络信息不同步,数据发送有延迟
- 解决方案
- 优化主从间的网络环境,通常放置在同一个机房部署,如使用阿里云等云服务器时要注意此现象
- 监控主从节点延迟(通过offset)判断,如果slave延迟过大,暂时屏蔽程序对该slave的数据访问
**slave-serve-stale-data**`` yes|no
- 开启后仅响应info、slaveof等少数命令(慎用,除非对数据一致性要求很高)
二、集群-哨兵模式
1、哨兵简介
- 哨兵:哨兵(sentinel)是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的 master并将所有slave连接到新的master。
- 哨兵的作用:
- 监控
- 不断的检查master和slave是否正常运行
- master存活检测,master和slave运行情况检测
- 通知
- 当被监控的服务器出现问题时,向其他(哨兵间,客户端)发送通知
- 自动故障转义
- 断开master于slave连接,选取一个slave作为master,将其他slave连接到新的master,并告知客户端新的服务器地址。
- 监控
注意:
配置一拖二的主从结构(一个主机 两个从机)
- 配置三个哨兵(配置相同,端口不同)
- 参看 sentinel.conf
- 启动哨兵
- redis-sentinel sentinel-端口号.conf
- 启动哨兵客户端
- redis-cli -p 哨兵端口号
3、sentinel.conf
# 哨兵的端口号,通常是redis端口前加 2
port 26379
# 哨兵的工作信息
dir /tmp
# 哨兵的监控主机,mymaster 自己起的名,2 表示如果有两个哨兵认定该主机宕机了,那么就是宕机了 (通常设定哨兵的数量一半加1)
sentinel monitor mymaster 127.0.0.1 6379 2
# 主机连接多长时间没有响应表示挂了(毫秒单位)
sentinel down-after-milliseconds mymaster 30000
# 新上任的master 同步数量
sentinel parallel-syncs mymaster 1
# 多长时间同步完成算有效,如果超过3分钟表示超市 (毫秒单位)
sentinel failover-timeout mymaster 180000
4、哨兵的工作原理
阶段1:监控阶段
- 获取各个sentinel【哨兵】的状态(是否在在线)
- 获取master的状态
- master属性
- runid
- role:master
- 各个slave的详细信息
- master属性
- 获取所有slave的状态(根据master中的slave信息)
- slave属性
- runid
- role:slave
- master_host、master_port
- offset
- slave属性
阶段2:保持联通
阶段3:故障转移
- 发现问题
- 竞选负责人
- 选新的master
- 新master上任,其他slave切换master
三、集群
1、集群简介
- 业务发展过程中遇到峰值瓶颈
- redis提供的服务OPS可以到达10万/秒 ,但是当前业务已经达到20万/秒
- 内存单机容量达到256G,当前业务需求内存容量1T
- 使用集群就可以解决上面的问题
- 集群架构
- 集群就是使用网络将活干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果
集群作用
数据存储设计
- 通过算法设计,计算出key应该保存的位置。
- 将所有的存储空间计算切割成16384份,每台主机保存一部分
- 每份代表的是一个存储空间,不是一个key的保存空间
- 将key按照计算出的结果放到对应的存储空间
集群内部通讯设计
Cluster配置
- 添加节点
**cluster-enabled yes|no **
- cluster配置文件名,该文件属于自动生成,仅用于快速查找文件并查询文件内容
**cluster-config-file <filename**``** nodes-6379.conf**``**>**
- 节点服务响应超时时间,用于判定该节点是否下线或切换为从节点
**cluster-node-timeout **``** **``**毫秒**
- master连接的slave最小数量
**cluster-migration-barrier **
- 添加节点
- Cluster节点操作命令
- 查看集群节点信息
**cluster**`` nodes
- 进入一个从节点 redis,切换其主节点
**cluster **``replicate
- 发现一个新节点,新增主节点
**cluster **``meet ip:port
- 忽略一个没有solt的节点
**cluster **``forget
- 手动故障转移
**cluster **``failover
- 查看集群节点信息
- redis-trib命令
- 添加节点
**redis-trib.rb**`` add-node
- 删除节点
**redis-trib.rb**`` del-node
- 重新分片
**redis-trib.rb**`` reshard
- 添加节点
四、集群常见问题
1、缓存预热
- 预热:服务器启动后 快速宕机
- 问题排查
- 请求数量较高
- 主从之间数据吞吐量较大,数据同步操作频度较高
- 解决方案
- 前置准备工作:
- 日常例行统计数据访问记录,统计访问频度较高的热点数据
- 利用LRU数据删除策略,构建数据留存队列
- 例如:storm与kafka配合
- 准备工作:
- 将统计结果中的数据分类,根据级别,redis优先加载级别较高的热点数据
- 利用分布式多服务器同时进行数据读取,提速数据加载过程
- 热点数据主从同时预热
- 实施:
- 使用脚本程序固定触发数据预热过程
- 如果条件允许,使用了CDN(内容分发网络),效果会更好
- 前置准备工作:
- 总结:
- 缓存预热就是系统启动前,提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候,先查询数据库,然后再将数据缓 存的问题!用户直接查询事先被预热的缓存数据!
2、缓存雪崩
数据库服务器崩溃(1)
- 系统平稳运行过程中,忽然数据库连接量激增
- 应用服务器无法及时处理请求
- 大量408,500错误页面出现
- 客户反复刷新页面获取数据
- 数据库崩溃
- 应用服务器崩溃
- 重启应用服务器无效
- Redis服务器崩溃
- Redis集群崩溃
- 重启数据库后再次被瞬间流量放倒
问题排查:
- 在一个较短的时间内,缓存中较多的key集中过期
- 此周期内请求访问过期的数据,redis未命中,redis向数据库获取数据
- 数据库同时接收到大量的请求无法及时处理
- Redis大量请求被积压,开始出现超时现象
- 数据库流量激增,数据库崩溃
- 重启后仍然面对缓存中无数据可用
- Redis服务器资源被严重占用,Redis服务器崩溃
- Redis集群呈现崩塌,集群瓦解
- 应用服务器无法及时得到数据响应请求,来自客户端的请求数量越来越多,应用服务器崩溃
- 应用服务器,redis,数据库全部重启,效果不理想
问题分析:
- 短时间范围内
- 大量的key 集中过期
解决方案(道)
- 更多的页面静态化处理
- 构建多级缓存架构 Nginx缓存+redis缓存+ehcache缓存
- 检测Mysql严重耗时业务进行优化 对数据库的瓶颈排查:例如超时查询、耗时较高事务等
灾难预警机制 监控redis服务器性能指标
- CPU占用、CPU使用率
- 内存容量
- 查询平均响应时间
- 线程数
限流、降级
- 短时间范围内牺牲一些客户体验,限制一部分请求访问,降低应用服务器压力,待业务低速运转后再逐步放开访问
解决方案(术)
- LRU与LFU切换
- 数据有效期策略调整
- 根据业务数据有效期进行分类错峰,A类90分钟,B类80分钟,C类70分钟
- 过期时间使用固定时间+随机值的形式,稀释集中到期的key的数量
- 超热数据使用永久key
定期维护(自动+人工)
- 对即将过期数据做访问量分析,确认是否延时,配合访问量统计,做热点数据的延时
加锁 慎用!
总结
缓存雪崩就是瞬间过期数据量太大,导致对数据库服务器造成压力。如能够有效避免过期时间集中,可以有效解决雪崩现象的出现 (约40%),配合其他策略一起使用,并监控服务器的运行数据,根据运行记录做快速调整。3、缓存击穿
数据库服务器崩溃(2)
系统平稳运行过程中
- 数据库连接量瞬间激增
- Redis服务器无大量key过期
- Redis内存平稳,无波动
- Redis服务器CPU正常
- 数据库崩溃
问题排查
- Redis中某个key过期,该key访问量巨大
- 多个数据请求从服务器直接压到Redis后,均未命中
- Redis在短时间内发起了大量对数据库中同一数据的访问
问题分析
- 单个key 高热数据
- key过期
解决方案(术)
- 预先设定
- 以电商为例,每个商家根据店铺等级,指定若干款主打商品,在购物节期间,加大此类信息key的过期时长
- 注意:购物节不仅仅指当天,以及后续若干天,访问峰值呈现逐渐降低的趋势
- 现场调整
- 监控访问量,对自然流量激增的数据延长过期时间或设置为永久性key
- 后台刷新数据
- 启动定时任务,高峰期来临之前,刷新数据有效期,确保不丢失
- 二级缓存
- 设置不同的失效时间,保障不会被同时淘汰就行
- 加锁
- 分布式锁,防止被击穿,但是要注意也是性能瓶颈,慎重!
总结:
- 缓存击穿就是单个高热数据过期的瞬间,数据访问量较大,未命中redis后,发起了大量对同一数据的数据库访问,导致对数据库服 务器造成压力。应对策略应该在业务数据分析与预防方面进行,配合运行监控测试与即时调整策略,毕竟单个key的过期监控难度 较高,配合雪崩处理策略即可。
4、缓存穿透
数据库服务器崩溃(3)
- 系统平稳运行过程中
- 应用服务器流量随时间增量较大
- Redis服务器命中率随时间逐步降低
- Redis内存平稳,内存无压力
- Redis服务器CPU占用激增
- 数据库服务器压力激增
- 数据库崩溃
问题排查
- Redis中大面积出现未命中
- 出现非正常URL访问
问题分析
- 获取的数据在数据库中也不存在,数据库查询未得到对应数据
- Redis获取到null数据未进行持久化,直接返回
- 下次此类数据到达重复上述过程
- 出现黑客攻击服务器
解决方案(术)
缓存null
- 对查询结果为null的数据进行缓存(长期使用,定期清理),设定短时限,例如30-60秒,最高5分钟
白名单策略
- 提前预热各种分类数据id对应的bitmaps,id作为bitmaps的offset,相当于设置了数据白名单。当加载正常数据时,放 行,加载异常数据时直接拦截(效率偏低)
- 使用布隆过滤器(有关布隆过滤器的命中问题对当前状况可以忽略)
实施监控
- 实时监控redis命中率(业务正常范围时,通常会有一个波动值)与null数据的占比
- 非活动时段波动:通常检测3-5倍,超过5倍纳入重点排查对象
- 活动时段波动:通常检测10-50倍,超过50倍纳入重点排查对象 根据倍数不同,启动不同的排查流程。然后使用黑名单进行防控(运营)
key加密
- 问题出现后,临时启动防灾业务key,对key进行业务层传输加密服务,设定校验程序,过来的key校验
- 例如每天随机分配60个加密串,挑选2到3个,混淆到页面数据id中,发现访问key不满足规则,驳回数据访问
总结
- 缓存击穿访问了不存在的数据,跳过了合法数据的redis数据缓存阶段,每次访问数据库,导致对数据库服务器造成压力。通常此类 数据的出现量是一个较低的值,当出现此类情况以毒攻毒,并及时报警。应对策略应该在临时预案防范方面多做文章。
- 无论是黑名单还是白名单,都是对整体系统的压力,警报解除后尽快移除。
五、性能指标监控
监控指标
- 性能指标:Performance
- 内存指标:Memory
- 基本活动指标:Basic activity
- 持久性指标:Persistence
- 错误指标:Error
1、性能监控
2、内存指标:Memory
3、基本活动指标:Basic activity
4、持久性指标:Persistence
5、错误指标:Error
6、监控方式
工具:
- Cloud Insight Redis
- Prometheus
- Redis-stat
- Redis-faina
- RedisLive
- zabbix
命令
- benchmark
- redis cli
- monitor
- showlog
7、压测指令
- benchmark
- 命令:
**redis-benchmark [-h ] [-p ] [-c ] [-n [-k**``**]**
- 范例1
**redis-benchmark**
说明:50个连接,10000次请求对应的性能
- 范例2
**redis-benchmark -c 100 -n 5000**
- 说明:100个连接,5000次请求对应的性能
- 命令:
- monitor
- 命令
monitor
打印服务器调试信息
- 命令
- showlong
- 命令
**showlong [operator]**
- get :获取慢查询日志
- len :获取慢查询日志条目数
- reset :重置慢查询日志
- 相关配置
**slowlog-log-slower-than 1000**
#设置慢查询的时间下线,单位:微妙**slowlog-max-len 100**
#设置慢查询命令对应的日志显示长度,单位:命令数
- 命令