大家好，我是一名Java后端程序员，每天开心的撸CRUD;

你猜这次我又要写个啥没有卵用的知识点呢?

不好意思，问的略微有点早了，啥提醒都没给，咋猜呢，对吧?

明天早上老板把我叫到办公室，对我说，“公司最近接了个电商小程序单子，你和王二狗，李狗蛋参加下需要剖析和设计，而后下个月开发，3个月内实现测试，上线交付”。

WC，WC，WC

。。。。。。。

“老板，老板，我没学过微信小程序，我是个Java后端程序员，你再招一个前端微信小程序开发吧”，我很低声的跟老板说。

老板很大声的吼道，“不会的货色，不会本人学吗?招新不要钱吗?你晓得往年行情有多差吗，接单子容易吗?不想干就G?”

我平很想发火怼老板，然而忽然想到;

上有农村年迈父母，下有襁褓小儿，媳妇还辞职在出租房带孩子。

我就低声回复：“噢，噢，好的，好的，我学。”

屌丝的人生就是这样，总得向生存抬头。

努力学习吧!!!等我技术牛逼了，把老板炒了。

上面间接上超重量级干货：

回归正题：怎么样更好的优化Redis性能?

一、优化的一些倡议

1、尽量应用短的key

当然在精简的同时，不要为了key的“见名知意”。对于value有些也可精简，比方性别应用0、1。

2、防止应用keys

keys , 这个命令是阻塞的，即操作执行期间，其它任何命令在你的实例中都无奈执行。当redis中key数据量小时到无所谓，数据量大就很蹩脚了。所以咱们应该防止去应用这个命令。能够去应用SCAN,来代替。

3、在存到Redis之前先把你的数据压缩下

redis为每种数据类型都提供了两种外部编码方式，在不同的状况下redis会主动调整适合的编码方式。

4、设置key有效期

咱们应该尽可能的利用key有效期。比方一些长期数据(短信校验码)，过了有效期Redis就会主动为你革除!

5、抉择回收策略(maxmemory-policy)

当Redis的实例空间被填满了之后，将会尝试回收一部分key。依据你的应用形式，强烈建议应用 volatile-lru(默认) 策略——前提是你对key曾经设置了超时。但如果你运行的是一些相似于 cache 的货色，并且没有对 key 设置超时机制，能够思考应用 allkeys-lru 回收机制，具体解说查看 。maxmemory-samples 3 是说每次进行淘汰的时候 会随机抽取3个key 从外面淘汰最不常常应用的(默认选项)。

maxmemory-policy 六种形式 :volatile-lru：只对设置了过期工夫的key进行LRU（默认值）allkeys-lru ： 是从所有key里 删除 不常常应用的keyvolatile-random：随机删除行将过期keyallkeys-random：随机删除volatile-ttl ： 删除行将过期的noeviction ： 永不过期，返回谬误

6、应用bit位级别操作和byte字节级别操作来缩小不必要的内存应用

bit位级别操作：GETRANGE, SETRANGE, GETBIT and SETBITbyte字节级别操作：GETRANGE and SETRANGE

7、尽可能地应用hashes哈希存储

8、当业务场景不须要数据长久化时，敞开所有的长久化形式能够获得最佳的性能

数据长久化时须要在长久化和提早/性能之间做相应的衡量.

9、想要一次增加多条数据的时候能够应用管道

10、限度redis的内存大小

(64位零碎不限度内存，32位零碎默认最多应用3GB内存)

数据量不可预估，并且内存也无限的话，尽量限度下redis应用的内存大小，这样能够防止redis应用swap分区或者呈现OOM谬误。(应用swap分区，性能较低，如果限度了内存，当达到指定内存之后就不能增加数据了，否则会报OOM谬误。能够设置maxmemory-policy，内存不足时删除数据)

11、SLOWLOG [get/reset/len]

slowlog-log-slower-than 它决定要对执行工夫大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录。slowlog-max-len 它决定 slowlog 最多能保留多少条日志，当发现redis性能降落的时候能够查看下是哪些命令导致的。

二、管道测试

redis的管道性能在命令行中没有，然而redis是反对管道的，在java的客户端(jedis)中是能够应用的：

示例代码：

//注：具体耗时，和本身电脑无关(博主是在虚拟机中运行的数据)/** * 不应用管道初始化1W条数据 * 耗时：3079毫秒 * @throws Exception */@Testpublic void NOTUsePipeline() throws Exception {    Jedis jedis = JedisUtil.getJedis();    long start_time = System.currentTimeMillis();    for (int i = 0; i < 10000; i++) {        jedis.set("aa_"+i, i+"");    }    System.out.println(System.currentTimeMillis()-start_time);} /** * 应用管道初始化1W条数据 * 耗时：255毫秒 * @throws Exception */@Testpublic void usePipeline() throws Exception {    Jedis jedis = JedisUtil.getJedis();     long start_time = System.currentTimeMillis();    Pipeline pipelined = jedis.pipelined();    for (int i = 0; i < 10000; i++) {        pipelined.set("cc_"+i, i+"");    }    pipelined.sync();//执行管道中的命令    System.out.println(System.currentTimeMillis()-start_time);}

hash的利用

示例：咱们要存储一个用户信息对象数据，蕴含以下信息： key为用户ID，value为用户对象(姓名，年龄，生日等)如果用一般的key/value构造来存储，次要有以下2种存储形式：

1、将用户ID作为查找key,把其余信息封装成一个对象以序列化的形式存储 毛病：减少了序列化/反序列化的开销，引入简单适应零碎(Complex adaptive system)批改其中一项信息时，须要把整个对象取回，并且批改操作须要对并发进行爱护。

2、用户信息对象有多少成员就存成多少个key-value对 尽管省去了序列化开销和并发问题，然而用户ID为反复存储。

Redis提供的Hash很好的解决了这个问题，提供了直接存取这个Map成员的接口。Key依然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值。( 外部实现：Redis Hashd的Value外部有2种不同实现，Hash的成员比拟少时Redis为了节俭内存会采纳相似一维数组的形式来紧凑存储，而不会采纳真正的HashMap构造，对应的value redisObject的encoding为zipmap,当成员数量增大时会主动转成真正的HashMap,此时encoding为ht )。

Instagram内存优化

Instagram可能大家都已相熟，以后炽热的拍照App，月沉闷用户3亿。四年前Instagram所存图片3亿多时须要解决一个问题：想晓得每一张照片的作者是谁(通过图片ID反查用户UID)，并且要求查问速度要相当的块，如果把它放到内存中应用String构造做key-value:

HSET "mediabucket:1155" "1155315" "939"HGET "mediabucket:1155" "1155315""939"

测试：1百万数据会用掉70MB内存，3亿张照片就会用掉21GB的内存。过后(四年前)最好是一台EC2的 high-memory 机型就能存储(17GB或者34GB的，68GB的太节约了),想把它放到16G机型中还是不行的。

Instagram的开发者向Redis的开发者之一Pieter Noordhuis询问优化计划，失去的回复是应用Hash构造。具体的做法就是将数据分段，每一段应用一个Hash构造存储. 因为Hash构造会在单个Hash元素在有余肯定数量时进行压缩存储，所以能够大量节约内存。这一点在下面的String构造里是不存在的。而这个肯定数量是由配置文件中的hash-zipmap-max-entries参数来管制的。通过试验，将hash-zipmap-max-entries设置为1000时，性能比拟好，超过1000后HSET命令就会导致CPU耗费变得十分大。

HSET "mediabucket:1155" "1155315" "939"HGET "mediabucket:1155" "1155315""939"

测试：1百万耗费16MB的内存。总内存应用也降到了5GB。当然咱们还能够优化，去掉mediabucket:key长度缩小了12个字节。

HSET "1155" "315" "939"HGET "1155" "315""939"

三、优化案例

1、批改linux中TCP监听的最大包容数量

/proc/sys/net/core/somaxconn is set to the lower value of 128.

在高并发环境下你须要一个高backlog值来防止慢客户端连贯问题。留神Linux内核默默地将这个值减小到/proc/sys/net/core/somaxconn的值，所以须要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的成果。 echo 511 > /proc/sys/net/core/somaxconn 留神：这个参数并不是限度redis的最大链接数。如果想限度redis的最大连接数须要批改maxclients，默认最大连接数为10000

2、批改linux内核内存调配策略

谬误日志：WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot orrun the command 'sysctl vm.overcommit_memory=1

redis在备份数据的时候，会fork出一个子过程，实践上child过程所占用的内存和parent是一样的，比方parent占用的内存为8G，这个时候也要同样调配8G的内存给child,如果内存无奈累赘，往往会造成redis服务器的down机或者IO负载过高，效率降落。所以内存调配策略应该设置为 1(示意内核容许调配所有的物理内存，而不论以后的内存状态如何)。 内存调配策略有三种 可选值：0、1、2。 0， 示意内核将查看是否有足够的可用内存供给用过程应用;如果有足够的可用内存，内存申请容许;否则，内存申请失败，并把谬误返回给利用过程。 1， 不论须要多少内存，都容许申请。 2， 只容许调配物理内存和替换内存的大小(替换内存个别是物理内存的一半)。

3、敞开Transparent Huge Pages(THP)

THP会造成内存锁影响redis性能，倡议敞开

Transparent HugePages ：用来进步内存治理的性能Transparent Huge Pages在32位的RHEL 6中是不反对的执行命令 echo never > /sys/kernel/mm/transparent_hugepage/enabled把这条命令增加到这个文件中/etc/rc.local