Redis里调整大小那些事儿，性能能不能蹭蹭往上涨？

Redis里调整大小那些事儿,性能能不能蹭蹭往上涨？

这事儿得分开看,就像给衣服改尺寸，有的地方改对了立马合身又精神，有的地方乱改一通，反而会扯破布料，Redis的性能优化也是这个理儿，关键看你动的是哪里，怎么动。

先说说最容易下手，也往往最见效的：内存大小相关配置。

Redis是个内存数据库,数据都放在内存里，所以内存的使用方式直接决定了它的速度和稳定性，这里有几个关键的“尺寸”可以调整。

第一个是 hash-max-ziplist-entries 和 hash-max-ziplist-value 这类参数，这是什么意思呢？（根据Redis官方文档）Redis为了节省内存，对小型的哈希（Hash）、列表（List）、集合（Set）、有序集合（ZSet）这些数据结构，不会直接用那种复杂的内部结构来存，而是用一种叫“ziplist”（压缩列表）的紧凑格式，你可以把它想象成一个打包得很紧的包裹。

hash-max-ziplist-entries 默认是512，意思是当一个哈希表里的键值对数量不超过512个时，Redis就把它打包成ziplist，如果超过了这个数，Redis就会把它“解包”，转换成一个更大的哈希表结构，这样查找速度更快，但占用的内存也会多一些。hash-max-ziplist-value 则是控制每个键或值的大小，默认64字节。

那调整它们有什么用？如果你的业务场景里，大部分哈希表都只有几十个元素，但偶尔有几个会涨到600个，那么Redis就会频繁地在ziplist和哈希表之间转换，这个转换过程是需要消耗CPU的，这时候，你适当把这个阈值（比如从512调到1024），就能减少转换次数，用稍微多一点点内存换来更稳定的性能，反过来，如果你的服务器内存非常紧张，但可以接受性能上的一点损失，你可以把这个值调小，强迫Redis更多使用ziplist来节省内存，这完全是一个时间和空间的权衡。

第二个重量级选手是 maxmemory，这个参数直接设定了Redis能使用的最大内存容量。（根据《Redis设计与实现》等资料） 如果不设置这个值，在64位系统下Redis会一直用光所有可用内存，这非常危险，很可能导致系统崩溃，所以一定要设。

设了 maxmemory 之后，当内存快用完时，就要触发淘汰策略，这是由 maxmemory-policy 决定的，默认策略是 noeviction，意思是内存满了之后，所有会占用更多内存的命令（比如写入新的key）都会报错，这显然会影响服务的可用性。

想让性能“蹭蹭涨”，你得选择一个合适的淘汰策略。allkeys-lru，它会尝试淘汰最近最少使用的键（LRU算法），不管这个键有没有设置过期时间，这在缓存场景下非常有用，能确保最热的数据留在内存里，如果你的数据访问有明显的热点，调整到这个策略性能提升会非常明显，因为内存里始终是大家最常访问的数据，命中率高了，速度自然就快了，还有 volatile-lru，它只淘汰那些设置了过期时间的键中的最近最少使用的，这适合数据有明确生命周期的场景。

再说说和持久化相关的“大小”问题。

Redis的持久化方式之一AOF（追加日志文件），它会记录每一个写命令，时间长了，这个AOF文件会变得非常大，而且里面可能有很多重复或无效的操作（比如对一个键先set后del），所以Redis提供了AOF重写机制来压缩这个文件。

这里有个参数 auto-aof-rewrite-min-size，表示AOF文件至少达到多大才会触发重写（默认64MB），还有 auto-aof-rewrite-percentage，表示当前AOF文件大小比上次重写后的大小增长了百分之多少才触发重写。

如果这个最小值设得太小,或者百分比设得太低，会导致AOF重写过于频繁，AOF重写是一个比较耗资源的操作（会fork子进程），频繁重写会消耗大量CPU和磁盘I/O，反而拖累正常请求的性能，但如果你设得太大，AOF文件会一直膨胀，不仅占磁盘，在Redis重启时加载AOF文件恢复数据的时间也会变得非常长，所以你需要根据你的磁盘性能和业务对重启速度的要求，找到一个平衡点。

网络缓冲区的大小。

这个可能稍微偏门一点,但也很重要。client-output-buffer-limit 这个参数是用来限制给每个客户端使用的输出缓冲区大小的，为什么要限制？如果一个客户端（比如一个慢速消费的订阅者，或者一个复制数据的从节点）读取速度很慢，而主Redis服务器发送数据很快，就会导致数据在这个客户端对应的输出缓冲区里堆积，如果不加限制，可能会耗尽服务器内存。

默认配置对于普通客户端、复制用的从节点、发布订阅客户端都有不同的限制值，如果你的场景里有大量的数据需要从主节点同步到从节点（比如从节点宕机很久后重连），默认的缓冲区限制可能不够，会导致复制连接中断，然后从节点需要重新全量同步，这个过程对网络和服务器负载都很大，这时候，适当调大针对从节点（slave）的 client-output-buffer-limit 值，可以保证复制的稳定性，从而间接提升整体服务的可靠性，这也是一种性能保障。

回到最初的问题：调整大小，性能能不能蹭蹭涨？答案是：能，但前提是你要清楚地知道你在调整什么，为什么调整，它不是一个简单的“把这个数字调大性能就好了”的魔法，你需要先监控你的Redis实例，发现瓶颈所在：是内存不够触发频繁淘汰？是数据结构转换太频繁？还是AOF重写影响性能？或者是复制总中断？

摸清了病因,再对症下药，调整对应的“尺寸”，才能真正让Redis的性能“蹭蹭往上涨”，否则可能就是瞎折腾，甚至适得其反，这就像老中医看病，得先号脉，再开方子。