Redis 性能下降严重,快来看看我的填坑手册!

业余杂谈 herman 111浏览
公告:“业余草”微信公众号提供免费CSDN下载服务,关注业余草微信公众号,添加作者微信:xmtxtt,发送下载链接帮助你免费下载!
本博客日IP超过1300,PV 1800 左右,急需赞助商。
打开支付宝首页搜“567452957”领红包,间接赞助博主,谢谢!

网上有非常多的文章在描述 redis hgetall 顺序、redis hgetall 慢、redis 避免hgetall、hgetall 性能、hgetall dump、redis hgetall优化、redis hgetall performance 等问题。这些问题平时你们可能遇不到,一旦遇到就是大问题。

每一个工具都有每个工具的优点和缺点。当一个软件提供的功能过多的时候,它就会过于复杂,过于臃肿。过多的功能,就会提供过多的选择,选择不当就会带来危害。今天我们一起来扯一扯 Redis 中的哪些命令不能乱用!

Redis 在你使用后,你会感觉它用起来非常的爽,但是爽过之后,你也会发现一些不爽的事情。就像你和你女朋友不带 TT 爽过之后,却发现你女朋友怀孕了。但你并没有能力或者做好准备,你就不会感觉到爽了。

Redis 不是万金油,也不是垃圾桶

在 Redis 中,有非常多的命令,刚开始用起来很爽,但是随着时间的推移你却发现一点也不爽!

面试中,我通常会问《Redis 是单线程结构,但为何单线程还能支持高并发?》、《Redis 和 Memcached 的区别》。大部分回答者都会说到一条:Redis 采用了非阻塞 IO。

但是在实际工作中你会发现,Redis 虽然采用了非阻塞 IO,但并不一定代表它就不阻塞 IO。就像我前面说的《Vector 真的线程安全的吗?》,还有 Hashtable 真的安全吗?Java 有垃圾回收,是不是就不会发生内存泄露?鱼香茄子怎么没鱼啊?……

当你意识到保险并不保险的时候,你才会去认真的阅读保险细则;当你的系统发生宕机时,你才会去拼命的填坑;当你的 Redis CPU 100% 的时候,你才会明白原来它是一个单线程的。

最近越来越多的用户反应,我们的系统在升级之后变的越来越卡。于是,我重点对卡的地方做了排查。发现很多地方存在乱用 Redis 命令的地方,因此便有了这篇 Redis 禁令。

Redis 中有很多命令是 O(N) 的。比如:keys、sort、hgetall、smembers、lrange、zrange、sinter 等。使用这些命令刚开始感觉很爽,但是随着数据的沉淀。使用它们却让 CPU 发生了饱和现象。

单线程的 redis 处理命令时只能使用一个 CPU,CPU 饱和是指 redis 把单核的 CPU 使用率跑到接近 100%。如果你过多的使用上面的那些命令,并且当并发比较高时,如果某个命令执行时间过长,会造成其他命令阻塞,对 redis 来说是致命的。这就是说,虽然 Redis 采用了非阻塞 IO,但它还是会发生阻塞。

除此之外,Redis 持久化也会引起阻塞。持久化引起主线程的阻塞操作主要有:fork 阻塞、AOF 刷盘阻塞、HugePage 写操作阻塞。

这些阻塞都会导致生产事故的发生。因此,我便对所有的开发人员做了培训,请少用或者尽量不要使用 O(N) 的命令。对于大对象统计出来后,采用分段进行 scan、hscan、sscan、zscan 操作。禁止使用 keys、flushall、flushdb 等命令。

这次我是想把所有的坑都填上,但是这套填坑手册你们先收藏一下吧。

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加QQ1群:135430763(2000人群已满),QQ2群:454796847(已满),QQ3群:187424846(已满)。QQ群进群密码:xttblog,想加微信群的朋友,可以微信搜索:xmtxtt,备注:“xttblog”,添加助理微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通!

本文原文出处:业余草: » Redis 性能下降严重,快来看看我的填坑手册!