Redis_注意事项

摘要: redis使用时要注意以下问题

注意事项

设置最大内存

一定要设置最大内存，否则物理内存用爆了就会大量使用Swap，写RDB文件时变得非常缓慢。

如果不限制导致内存占用过大时，可能会被linux内核强制kill

可以在/var/log/messages文件中看见如下信息：

Out of memory: Kill process 2030 (redis-server) score 679 or sacrifice child

内存限制

如果超过最大内存而且没有设置删除策略或者删除策略已不满足，则无法写入

不要使用过长的key

Key 可以是任意类型,最后都存成byte[]

Key 不能太长，比如1024字节，但也不追求太短，建议用":"分隔表名，用"."作为单词间的连接。

key数量限制

一个实例最大可以存储 2^32个key

hash, list, set, sorted set, 可以存储 2^32个元素

value长度限制

单个value长度限制为最大512M

RDB&AOF

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。

在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；

如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒

当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件
RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。

AOF为追加操作，每次耗时不会太长，2.2之后的版本可以配置追加的达到一定大小后自动重写AOF，减小无用的存储

在不重写的情况下，如果你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录

AOF的恢复速度比RDB慢得多

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集

生产环境代码不要使用keys指令

keys执行会做全库扫描，非常消耗redis服务器的cup，对于单核cup的redis来说，频繁的keys操作，会导致CPU很容易就被占满

修改最大连接数

linux的默认连接数(128),和redis的默认最大连接数量(511)一般对于生产环境来说都太小。生产环境或者压测环境注意修改相应的数值为合适的值,redis客户端的最大连接数不要忘记调整