redis常用优化方法

n 使用管道（Pipeline）

Redis的底层通讯协议对管道提供了支持，通过管道，可以一次性发送多条命令给

Redis，在执行完后一次性将结果取回。

使用管道，可以减少客户端和Redis的通信次数，降低网络延时，从而提供性能。

Redis的管道功能在命令行中没有，但Redis是支持管道的，而且在各个语言版的client中

都有相应的实现。

n 精简键名和键值

n 合理设计存储的数据结构和数据关系，尽量减少数据冗余

n 尽量使用mset来赋值，比set效率高一个数量级；类似的还有lpush、zadd等都可以一次输

入多个指令

n 如果可能，尽量使用Lua脚本来辅助获取或操作数据

n 尽量使用hash结构来存储对象

将一个对象存储在hash类型中会占用更少的内存，并且可以更方便的存取整个对

象，省内存的原因是新建一个hash对象时开始是用zipmap来存储的。

n 使用hash结构时，应尽量保证每个key下面的<field, value>的数目不超过限制（默认值为

64），否则插入效率下降十分明显，同样，内存开销也会显著增加

配置使用ziplist以优化list

如果list的元素个数小于配置值list-max-ziplist-entries且元素值字符串的长度

小于配置值list-max-ziplist-value，则可以编码成ziplist类型存储，否则采用 Dict 来

存储，Dict实际是Hash Table的一种实现。

n 配置使用intset以优化set

当set集合中的元素为整数且元素个数小于配置set-max-intset-entries值时，使用

intset数据结构存储，否则转化为Dict结构

n 配置使用ziplist以优化sorted set

当sorted set的元素个数及元素大小小于一定限制时，它是用ziplist来存储。这个

限制的配置如下：zset-max-ziplist-entries、zset-max-ziplist-value

n 配置使用zipmap以优化hash

当entry数量没有超过hash-max-ziplist-entries指定的限制，并且值的最大长度没

有超过hash-max-ziplist-value指定的限制时，会用zipmap来编码。

注意：HashMap的优势就是查找和操作的时间复杂度都是O(1)的，而放弃Hash采用一

维存储则是O(n)的时间复杂度，如果成员数量很少，则影响不大，否则会严重影响性能，

所以要权衡好些个值的设置，在时间成本和空间成本上进行权衡。

n 一定要设置maxmemory

设置Redis使用的最大物理内存，也就是使用了这么多物理内存后就开始拒

绝后续的写入请求，该参数能保护Redis不会因为使用了过多的物理内存而严重

影响性能甚至崩溃。

n 对排序的优化

1：尽量让要排序的Key存放在一个Server上

如果采用客户端分片，那么具体决定哪个key存在哪个服务器上，是由

client端采用一定算法来决定的，因此可以通过只对key的部分进行hash。比

如：client如果发现key中包含{}，那么只对key中{}包含的内容进行hash。

如果采用服务端分片，也可以通过控制key的有效部分，来让这些数据分配

到同一个插槽中。

2：尽量减少Sort的集合大小

如果要排序的集合非常大, 会消耗很长时间，Redis单线程的，长时间的排

序操作会阻塞其它client的请求。解决办法是通过主从复制，将数据复制到多个

slave上，然后只在slave上做排序操作，并尽可能的对排序结果缓存。

n 考虑采用复制+RDB的方式

使用复制机制来实现高可用，数据采用RDB的方式进行持久化备份，建议只

在Slave上持久化RDB文件，而且只要在一个相对较长的时间备份一次就够了，比

如只保留save 900 1这条规则，大致就是15分钟保存一次。

这样的方式避免了AOF带来的持续的IO，也避免AOF Rewrite最后将rewrite

过程中产生的新数据写到新文件所造成的阻塞。代价是如果Master/Slave同时倒

掉，可能会丢失15分钟的数据。

n 考虑在一台服务器启动多个Redis实例

由于Redis使用单线程，为了提高CPU利用率，可以在同一台服务器上启动

多个Redis实例，但这可能会带来严重的IO争用，除非Redis不需要持久化，或者

有某种方式保证多个实例不会在同一个时间重写AOF。