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

网上有非常多的文章在描述 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 等命令。

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

： » Redis 性能下降严重，快来看看我的填坑手册！