国内最大ae模板下载网站,广州网站设计价格,小工厂如何找外贸公司合作,p2p贷款网站建设一、常见命令
1.1 过期时间意外丢失
原因#xff1a;
SET命令如果不设置过期时间#xff0c;那么Redis会自动【擦除】这个key的过期时间
1.2 DEL命令阻塞redis
key是String类型时#xff0c;DEL时间复杂度是O(1)key是List/Hash/Set/ZSet类型#xff0c;DEL时间复杂度是…
一、常见命令
1.1 过期时间意外丢失
原因
SET命令如果不设置过期时间那么Redis会自动【擦除】这个key的过期时间
1.2 DEL命令阻塞redis
key是String类型时DEL时间复杂度是O(1)key是List/Hash/Set/ZSet类型DEL时间复杂度是OMM为元素数量
1.3 RANDOMKEY阻塞redis
RANDOMKEY命令会从redis中随机取出一个key首先会检查这个key是否过期如果已经过期那么Redis会删除它这个过程就是懒惰清理
清理完之后redis还要找出一个【不过期】的key返回给客户端。
整个流程就是这样的【在master执行RANDOMKEY】 master 随机取出一个 key判断是否已过期 如果 key 已过期删除它继续随机取 key 以此循环往复直到找到一个不过期的 key返回
如果有大量key已经过期还没来得及清理这个循环就卡住了耗时都花费在了清理过期key寻找不过期key上。
【slave执行RANDOMKEY】
slave是不会主动清理过期key的当一个key要过期时master会先清理删除它然后向slave发送一个DEL命令告知slave也需要删除这个key以此达到主从库的数据一致性。
1.4 SETBIT导致redis OOM
在使用setbit时需要注意offset的大小操作过大的offset也会引发redis的卡顿
1.5 MONITOR导致redis OOM
当执行monitor命令时redis会把每条命令写到客户端的【输出缓冲区】中然后客户端从这个缓冲区读取服务器返回的结果。
如果redis的QPS很高会导致这个输出缓冲区内存持续增长占用redis大量的内存资源如果机器资源内存不足将会面临OOM的风险。
二、数据持久化
两种持久化方式rdb和aof
rdb是数据快照而aof会记录每一个写命令到日志文件中。
2.1 master宕机slave数据也跟着丢失
如果redis采用如下模式部署就会发生数据丢失的问题
master-slave哨兵部署实例master没有开启数据持久化功能Redis进程使用supervisor管理并配置为【进程宕机自动重启】
此时如果master宕机就会导致如下问题
master宕机哨兵还未完成切换此时master进程立即被supervisor自动拉起但是master没有开启任何数据持久化启动后是一个【空】实例此时slave为了跟master保持一致会自动清空实例中的所有数据导致slave也成了一个空实例
这样master和slave中的数据就全部丢失了。
这时业务应用访问redis时发现缓存中没有任何数据就会把请求全部打到后端数据库中进一步引发缓存雪崩对业务影响非常大。
改进
redis实例不使用进程管理工具自动拉起master宕机后让哨兵发起切换把slave提升为master角色切换完成后再重启master使其退化为slave。
2.2 AOF everysec真的不会阻塞主线程吗
这种方案的工作方式为
redis后台线程每隔1秒就会把AOF中的数据刷到磁盘上。【把aof刷盘的耗时操作放到了后台子线程中去执行避免了对主线程的影响】
刷盘流程 主线程在写 AOF page cachewrite系统调用前先检查后台 fsync 是否已完成 后台 fsync已完成主线程直接写AOF page cache 未完成则检查距离上次fsync过去多久 距离上次fsync成功在2秒内那么主线程会直接返回不写AOF page cache 距离上次fsync成功大于2秒主线程强制写AOF page cache 由于磁盘IO负载过高此时后台线程fsync会发生阻塞那主线程在写AOF page cache时也会发生阻塞等待操作同一个 fdfsync 和 write 是互斥的一方必须等另一方成功才可以继续执行否则阻塞等待
即使配置的AOF刷盘策略是everysec也依旧会有阻塞主线程的风险。
原因磁盘IO负载过高导致fsync阻塞进而导致主线程写AOF page cache也发生阻塞。
2.3 AOF everysec真的只会丢失1秒数据
参考步骤4后台线程在执行fsync刷盘时主线程最多等待2秒不会写AOF page cache.
如果此时 Redis 发生了宕机那么AOF 文件中丢失是 2 秒的数据而不是 1 秒
为什么主线程会等待2秒不写AOF page cache
降低主线程阻塞的风险【如果无脑写AOF page cache主线程会立即阻塞住】如果fsync阻塞主线程就会给后台线程留出1秒的时间等待fsync成功
2.4 RDB和AOF rewrite时Redis发生OOM
redis在把RDB快照和AOF rewrite时会采用创建子进程的方式把实例中的数据持久化到磁盘上。
创建子进程时会调用操作系统的fork函数fork执行完成后父进程和子进程会同时共享同一份内存数据。
此时父进程依旧是可以接收写请求的而进来的写请求会采用Copy On Write(写时复制)的方式操作内存数据。【先拷贝再修改这里需要拷贝原有的内存数据到新内存中】
如果业务特点是【写多读少】且OPS非常高在RDB和AOF 的rewrite期间就会产生大量的内存拷贝工作这期间修改key的范围越广新申请的内存就越多如果机器资源不足就会面临OOM的风险
三、主从库同步
3.1 主从复制会丢数据吗
会,redis的主从复制时采用【异步】方式进行的。
如果master突然宕机可能会有部分数据未同步到slave的情况。
3.2 同样命令查询一个key主从库却返回了不同的结果
如果一个key已经过期但是这个key还未被master清理此时在slave上查询这个key会返回什么结果
返回结果取决于以下因素
redis版本【3.2以下版本在slave上查询一个key时并不会判断这个key是否已经过期而是无脑返回给客户端结果】具体执行的命令机器时钟【根据本机时钟判断是否过期】
slave 查询过期 key经历了 3 个阶段 3.2 以下版本key 过期未被清理无论哪个命令查询 slave均正常返回 value 3.2 - 4.0.11 版本查询数据返回 NULL但 EXISTS 依旧返回 true 4.0.11 以上版本所有命令均已修复过期 key 在 slave 上查询均返回「不存在」
3.3 主从切换导致缓存雪崩
如果slave的机器时钟比master快很多从slave的角度来看redis中的数据存在大量过期。
此时如果操作【主从切换】把slave提升为新的master成为master后就会开始大量清理过期key就会导致以下结果
master大量清理过期key主线程发生阻塞此时无法处理客户端请求redis中数据大量过期引发雪崩
当 master / slave 机器时钟严重不一致时对业务的影响非常大
所以如果你是 DBA 运维一定要保证主从库的机器时钟一致性避免发生这些问题。
3.4 master/slave大量数据不一致
redis的maxmemory配置可以控制整个实例的内存使用上限超过这个上限并且配置了淘汰策略那么实例就开始淘汰数据。
如果master/slave配置的maxmemory不一样那此时就会发生数据不一致。
5.0版本增加了一个配置项replica-ignore-maxmemory默认 yes
3.5 slave竟然有内存泄漏的问题
redis内存泄漏
redis使用的是4.0以下版本slave的配置项为read-onlyno从库可写向slave写入了有过期时间的key
这时的 slave 就会发生内存泄露slave 中的 key即使到了过期时间也不会自动清理。
如果你不主动删除它那这些 key 就会一直残留在 slave 内存中消耗 slave 的内存。
最麻烦的是你使用命令查询这些 key却还查不到任何结果
4.0以上版本修复了这个问题
最好的方案是
制定一个redis使用规范slave必须强制设置为read-only不允许写这样不仅可以保证master/slave的数据一致性还避免了slave内存泄漏的问题。
3.6 为什么主从全量同步一直失败
redis的【复制风暴】
主从全量同步失败又重新开始同步之后又同步失败以此往复恶性循环持续浪费机器资源。
导致该问题的原因
master的实例数据过大slave在加载RDB时耗时过长复制缓冲区配置过小master写请求量很大
