redis学习笔记之十五：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。