360SDN.COM

首页/Redis/列表

Redis 一夜之间不见 90000 个 Key ? 数据丢失?淡定!

来源:ITPUB  2017-09-12 10:09:33    评论:0点击:

点击上方 “ITPUB” 一起玩耍哦~

Redis 大部分应用场景是纯缓存服务,请求后端有 Primary Storage 的组件, 如 MySQL,HBase; 请求 Redis 的键未命中,会从 primary Storage 中获取数据返回,同时更新 Redis 缓存。

如果少量数据丢失,相当于请求” 缓冲未命中 “; 一般对业务的影响是无感知的。

但现在 Redis 用作存储的业务场景变多,数据丢失对业务是致命的影响。


本文简单讨论 Redis 常见数据” 丢失 “现象,以及怎么规避;会列举几个生产中有意思的情节。

记 1 次 Redis” 数据丢失 “的故障排查

Redis 数据被丢失问题,发生次数也很多; 如何快速定位问题和避免呢。

先分享一个小故事(大家都喜欢带情节的片,不对是技术文章)

情节:我的 Redis 掉了 90000 多个 Keys, 是不是 DBA 有删除操作?

(时间:12-04 日;故事人物:RD(研发工程师) 和 DBA; 故事:Redis 一夜之间不见 90000 个 key)

RD: 我们 Redis 集群中,以 “t_list” 前缀的 90000 多 key 今早发现都掉了,其他 key 都在,是不是 DBA 有清理操作啊?

DBA:没有维护性操作 (一脸懵 B 和无辜), 先止损,把 Key 从 Primary store 中导入 Redis;我先分析一下原因,有结果了通知你;定位问题前,你也关注一下,避免二次发生。

RD:“已从 MySQL 把 key 导入到 Redis. 好的,等你消息。”

然后 RD 就下楼了,DBA 扣上他的 25 元的 boss 耳机,开始自言自语 Troubleshooting.

“这部分 key 未设置 TTL, 查看监控的 expired_keys 基本都是 0”

“是否达到了 maxmeory,key 被强制驱逐淘汰了? 查看监控 used_memory_pct 未到 100%,查看 evicted_keys 一直为 0,最近 24 小时无 key 被淘汰”

“只是部分 key 丢失,而且都是同一个 key 前缀,说明这个凶手很了解业务;查看监控的实例总 key 数, keys 指标,发现果断 keys 果断下降,但未变为 0,排除 Flushall/flushdb 和 Redis, 定位是程序或人为操作”

“如果程序主动删除 key, 就只能是 DEL 操作,查看监控 comdstat_del 指标,表示每秒执行的 Del 次数,果然平时基本为 0,昨晚 22:01 开始有每秒几十个的 del”

“再查看 slowlog, 22:01 时,执行 ‘ KEYS tlist*’ 的命令,获取这类 key,进行批量清理”

这时问题定位了, 一首歌多的时间。 

然后 DBA 通知 RD 排查的结论,让其他排查程序或人为操作;

分析证据简述如下:

从 03 日的 Redis key 监控可见,22:00 到 22:40 这个数据 key 个数下降 30000(1 个分片,此集群共 3 个分片)

03 日 22:00~22:40 分之间,Redis 的 DEL 操作大约 12 个,持续 40min; 删除 126040 约 29000 个 key.(3 个分片,共删除约 90000 个 key)

查看 slowlog 监控,2015-12-03 22:01:01 时间点,执行 KEYS “tlist*” 获取所有 key 的前缀, 目的应该是执行后面的 DEL 操作

说明:精细化的监控告警很重要。

数据丢失的影响

Redis 存储的应用场景,数据丢失是不能接受的;

因为 Redis 的持久化特性,数据还原很难保证一致性,因 rdb 全备和 aof 重写备份,RPO 不能像 MySQL 这样保证恢复到故障操作的前一个事务。

· 缓存的应用场景,如果大量缓存数据丢失,往往导致后端存储组件” 打死 “,应用程序雪崩的情况

常见 Redis 数据丢失的情况

· 程序 bug 或人为误操作

· 因客户端缓冲区内存使用过大,导致大量键被 LRU 淘汰

· 主库故障后自动重启,可能导致数据丢失

· 网络分区的问题,可能导致短时间的写入数据丢失

· 主从复制数据不一致,发生故障切换后,出现数据丢失

· 大量过期键,同时被淘汰清理

程序 bug 或人为误操作

如前文情节 1,程序 bug 误删除数据; DBA/RD 误操作执行 flushall/flushdb 这类命令。

这类问题的预防和监控

1 重命名危险命令:keys(程度大批量误删除,很多通过 keys 获取键后再删除),flushall,flushdb

2 细化几个重要的监控项:

· 实例当前的键个数 (dbsize/info), 当大量键丢失时,可通过此项历史监控图,定位发生的时间范围

· 各类删除命令的执行数监控:cmdtats_flushall, 

cmdstats_flushdb,cmdstat_del

对应时间范围,确认具体是什么操作

因客户端缓冲区内存使用过大,导致大量键被 LRU 淘汰

因客户端缓冲区的内存大小很难限制, 它们消耗的内存数会计算在 used_memory 内;如果使用不当,导致缓冲区内存使用过大,达到 maxmemory 限制;(缓存场景)会导致大量的键被淘汰,最坏会把所有键清理,缓冲无键可淘汰,写入失败。相当于整个缓冲失效,对业务影响较大。

关于 Redis 客户端缓冲区问题,详细分析见之前文章 Redis Clients Two Buffers

这类问题的预防和监控:

1 业务容量规划时把缓冲正常消耗计算在内,合理高大 maxmemory 的限制;

每个实例最好可预留几百 M(大小根据客户端连接数和 key 的使用有关,根据大小集群合理调整)

2 对输出缓冲区设置合理 limit;如 normal 设置 10MB, SLAVE 设置 1GB 等。 如果复制因 slave 线程输出缓冲区反复同步,需临时调大 slave client-output-buffer,要同时调大 maxmemory 限制。

说明:关于 Redis 复制中断和无限同步,详细分析请见 Redis 复制中断和无限同步问题

3 主要监控

监控内存使用大小 used_memory

监控两个 buffer 的使用量 client_longest_output_list 和 client_biggest_input_buf

监控键的 LRU 驱逐数量:evicted_keys

主库故障后自动重启,可能导致数据全部丢失

这种故障发生,极有可能数据全部丢失。

问题发生的现象:时间点 T1, 主库故障关闭了,因设置有自动重启的守护程序,时间点 T2 主库被重新拉起,因 (T2-T1) 时间间隔过小,未达到 Redis 集群或哨兵的主从切换判断时长;这样从库发现主库 runid 变了或断开过,会全量同步主库 rdb 清理,并清理自己的数据。

而为保障性能, Redis 主库往往不做数据持久化设置,那么时间点 T2 启动的主库,很有可能是个空实例(或很久前的 rdb 文件)。

这种问题发生时间间隔,一般小于 1 分钟,可能监控告警无法感知到。

这类总是的预防和监控:

1 强烈反对 Redis 粗暴地设置自动重启

2 这种监控键个数的变化,缓存命中率,同时 ELK 类型准实时监控 redis 日志变化并告警

建议:数据库这类重 “状态性” 服务,不建议程序暴力自动重启

网络分区的问题,可能导致短时间的写入数据丢

这种问题出现丢失数据都很少,网络分区时,Redis 集群或哨兵在判断故障切换的时间窗口,这段时间写入到原主库的数据,5 秒~ 15 秒的写入量。

详细分析参考:

Reply to Aphyr attack to Sentinel

redis-sentinel-at-flickr

图片 (引至参考 2): Redis 哨兵结构的网络分区导致的 “split-brain” 场景


主从复制数据不一致,发生故障切换后,出现数据丢失

主从数据出现不一致,发生故障切换,从库提升为主后,导致数据丢失的情况。

关于 Redis 复制数据不一致,请参考 Redis 复制主从数据不 - 致

大量过期键,同时被淘汰清理

这类情况不是真正的 “数据丢失”,只是定期主动清理 Redis 堆积的过期键,会导致 Redis 的键个数 (dbsize) 出现陡降 (最大能达 20%)。业务方常误以为有数据丢失。

这时可通过监控过期键淘汰的数量:expireed_keys 的增长量,与 dbsize 键总数减少数据量是否相等。


今日话题

欢迎大家评论区留言补充,遇到的数据丢失场景。

转载自:Roger Zhuo 的博客

作者:Roger Zhuo

原文链接:

https://zhuoroger.github.io/2016/08/14/redis-data-loss/


与 100 + 技术大牛面对面

SACC2017

作为国内最受欢迎的架构师盛会,2017 第九届中国系统架构师大会 (SACC) 将于将于 2017 年 10 月 19-21 日在北京新云南皇冠假日酒店震撼来袭。

大会以 “云智未来” 为主题,云集国内外顶级专家,围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置 2 大主会场,18 个技术专场;邀请来自互联网、金融、制造业、电商等多个领域,100 余位技术专家及行业领袖来分享他们的经验;并将吸引 4000 + 人次的系统运维、架构师及 IT 决策人士参会,为他们提供最具价值的交流平台。

点击“阅读原文”与100+技术大牛面对面,立享购票7.8折优惠~

阅读原文

为您推荐

友情链接 |九搜汽车网 |手机ok生活信息网|ok生活信息网|ok微生活
 Powered by www.360SDN.COM   京ICP备11022651号-4 © 2012-2016 版权