本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
网上有非常多的文章在描述 redis hgetall 顺序、redis hgetall 慢、redis 避免hgetall、hgetall 性能、hgetall dump、redis hgetall优化、redis hgetall performance 等问题。这些问题平时你们可能遇不到，一旦遇到就是大问题。
每一个工具都有每个工具的优点和缺点。当一个软件提供的功能过多的时候，它就会过于复杂，过于臃肿。过多的功能，就会提供过多的选择，选择不当就会带来危害。今天我们一起来扯一扯 Redis 中的哪些命令不能乱用！
Redis 在你使用后，你会感觉它用起来非常的爽，但是爽过之后，你也会发现一些不爽的事情。就像你和你女朋友不带 TT 爽过之后，却发现你女朋友怀孕了。但你并没有能力或者做好准备，你就不会感觉到爽了。
在 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）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Redis 性能下降严重，快来看看我的填坑手册！