redis优化

redis 数据库常用命令

redis数据库采用key-value（键值对）的数据存储形式。所使用的命令是set与get命令

设置键 值

20.0.0.11:6379> set lcx 123 
OK
20.0.0.11:6379> set abc 321
OK
20.0.0.11:6379> set cba 123
OK

查看键 值

20.0.0.11:6379> keys * #查看键
1) "cba"
2) "abc"
3) "lcx"
20.0.0.11:6379> get lcx #查看键的值
"123"

key相关命令

keys：获取符合规则的键值列表

20.0.0.11:6379> keys * #查看所有的库
1) "myset:__rand_int__" 
2) "counter:__rand_int__"
3) "key:__rand_int__"
4) "cba" #自己创建的
5) "mylist"
6) "lcx" #自己创建的
7) "abc" #自己创建的

20.0.0.16:6379> keys a* #查看以a开头的键
1) "aaa"
2) "abc"

20.0.0.16:6379> keys a? #查看以a开头的两位名称的键
1) "a1"
20.0.0.16:6379> keys a?? #查看以a开头的三位名称的键
1) "abc"
2) "a22"
3) "aaa"
20.0.0.16:6379> keys a??? #查看以a开头的四位名称的键
1) "a333"

exists：判断键值是否存在

20.0.0.16:6379> exists a
(error) MOVED 15495 20.0.0.14:6379
20.0.0.16:6379> exists abc
(integer) 1

del：删除当前数据库的指定key

20.0.0.16:6379> del abc
(integer) 1

type：获取key队形的value值类型

20.0.0.16:6379> type aaa
string

rename（覆盖）/renamenx（不覆盖重命名）：对已有的key进行重命名
rename命令是对key进行重命名，其命令格式为：rename 源 key 目标 key。使用rename命令进行重命名时，无论目标key是否存在都进行重命名，且源key的值会覆盖目标key的值。在实际使用过程中，建议先用exists命令查看目标key是否存在，然后再决定是否执行rename命令，以避免覆盖重要数据。
renamenx命令的作用是对已有key进行重命名，并检测新名是否存在。其命令格式与rename的命令格式除命令关键字不同外基本相同，renamenx 源 key 目标 key 。使用renamenx命令进行重命名时，如果目标key存在则不进行重命名。

dbsize：查看当前数据库中key的数目

20.0.0.12:6379> dbsize
(integer) 4

多数据库常用命令

多数据库间切换

redis在没有任何改动的情况下默认包含16个数据库，数据库名称是用数字0-15来依次命名的。使用select命令可以进行redis的多数据库之间的切换，命令格式为selectindex，其中index表示数据库的序号。而使用redis-cli连接redis数据库后，默认使用的是序号0的数据库。
如下所示，使用select命令切换数据库后，会在前端的提示符中显示当前所在的数据库序号如

127.0.0.1:6379[10]>"表示当前使用的是序号为10的数据库；若当前使用的数据库是序号为0的数据库，提示符中则不显示序号，如"127.0.0.1:6379>"表示当前使用的是序号为0的数据库
20.0.0.11:6379> SELECT 10 #切换到第11个库，因从0计数所以第11为10 OK

多数据库间移动数据

redis的多数据库在一定程度上是相对独立的，例如在数据库0上面存放的lcx在其他的1-15的数据库上是无法查看到的。
redis数据库提供了一个move的命令，可以进行多数据库的数据移动。命令的基本语法格式为"move key dbindex"。其中”key“表示当前数据库的目标键，”dbindex“表示目标数据库的序号。

20.0.0.11:6379[10]> keys *
(empty list or set) #此时为空
20.0.0.11:6379> MOVE lcx 10 #将自建的一个库转移到第11个库中
(integer) 1
20.0.0.11:6379> SELECT 10
OK
20.0.0.11:6379[10]> keys *
1) "lcx"
20.0.0.11:6379> SELECT lcx #原有的库将被移除
(error) ERR invalid DB index

清除数据库内数据

redis数据库的整库数据删除主要分为两个部分：清空当前数据库数据，使用flushdb命令实现；清空所有数据库的数据，使用flushall命令实现。但是，数据清空操作比较危险，生产环境下一般不建议使用。

20.0.0.11:6379[10]> FLUSHDB #清空当前库的内容
OK
20.0.0.11:6379[10]> keys *
(empty list or set)

20.0.0.11:6379> FLUSHALL #清空所有库的内容
OK

redis持久化

持久化概述

Redis是运行在内存中，内存中的数据断电丢失
为了能够重用Redis数据，或者防止系统故障，需要将Redis中的数据写入到磁盘空间中，即持久化

持久化分类

RDB方式：创建快照的方式获取某一时刻Redis中所有数据的副本
（缺点：只能是一个时刻，不可以连续，存在盲区，可能导致少量数据丢失）
AOF方式：将执行的写命令写到文件的末尾，以日志的方式来记录数据的变化
（缺点：日志文件的量多，人力成本大）
注意：
生产环境RDB+AOF方式，两个快照中间部分采用AOF方式，查找日志中对应时间的写命令

RDB持久化

是Redis默认的持久化方式，默认文件名为dump.rdb，在/var/lib/redis/6379/目录下

触发条件

在指定的时间间隔内，执行指定次数的写操作（配置文件控制）
执行save或者是bgsave（异步）命令
执行flushall命令，清空数据库所有数据
执行shutdown命令，保证服务器正常关闭且不丢失任何数据

优缺点

适合大规模的数据恢复
如果业务对数据完整性和一致性要求不高，RDB是很好的选择
数据的完整性和一致性不高
备份时占用内存

通过RDB文件恢复数据

将dump.rdb文件拷贝到redis的安装目录的bin目录下，重启redis服务即可

save 900 1 #900秒内至少一次写操作
save 300 10 #300秒内至少10次写操作
save 60 10000 #60秒内至少10000次写操作

只要满足其一都会触发快照操作，注释所有的save项表示关闭RDB

dbfilename dump.rdb #RDB文件名称
dir /var/lib/redis/6379 #RDB文件路径
rdbcompression yes #是否进行压缩

AOF持久化

• Redis默认不开启
• 弥补RDB的不足（数据的不一致性）
• 采用日志的形式来记录每个写操作，并追加到文件中
• Redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
• 根据AOF文件恢复数据
  将appendonly.aof文件拷贝到redis安装目录的bin目录下，重启redis服务即可
• 配置文件选项

appendonly yes #开启AOF持久化
appendfilename "appendonly.aof" #AOF文件名称
#appendfsync always #同步持久化，每次发生数据变化会立刻写入磁盘；
appendfsync everysec #默认推荐，每秒异步记录一次（默认值）
#appendfsync no #不同步，交给操作系统决定如何同步
aof-load-truncated yes #忽略最后一条可能存在问题的指令

AOF重写机制

AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多
当AOF文件的大小超过所设定的阀值时，Redis就会对AOF文件的内容压缩
AOF的重写的原理
Redis会fork出一条新进程，读取内存中的数据(并没有读取旧文件)，并重新写到一个临时文件中，最后替换旧的aof文件

AOF的重写配置

no-appendfsync-on-rewrite no #在日志进行BGREWRITEAOF时， 如果设置为yes表示新写操作不进行同步fsync,只暂存在缓冲区里，避免造成磁盘I0操作冲突，等重写完成后在写入。redis中默认为no
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写时AOF文件大小两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。当AOF文件到达64M的时候，发生BGREWRITEAOF操作

redis性能管理

查看redis内存使用

20.0.0.11:6379> info memory
# Memory
used_memory:2655992 #内存使用总量
used_memory_human:2.53M
………………
mem_fragmentation_ratio:2.08 #内存碎片率
mem_fragmentation_bytes:2820424

内存碎片率介绍

操作系统分配的内存值used_memory_rss除以redis使用的内存值
used_ memory计算得出
内存碎片是由操作系统低效的分配/回收物理内存导致的
不连续的物理内存分配
跟踪内存碎片率对理解redis实例的资源性能是非常重要的

• 内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
• 内存碎片率超过1.5,说明redis消耗了实际需要物理内存的150%，其中50%是 内存碎片率
• 内存碎片率低于1的，说明Redis内存分配超出了物理内存,操作系统正在进行内存交换
  （内存碎片率为1是最佳，低于1访问速度会慢，高于1说明碎片太多）

内存使用率介绍

redis实例的内存使用率超过可用最大内存，操作系统将开始进行

内存与swap空间交换（这时redis响应速度会变慢）

避免内存交换

针对缓存数据大小选择
尽可能的使用Hash数据结构
设置key的过期时间

如何回收key

• 保证合理分配redis有限的内存资源
• 当达到设置的最大阈值时，需选择一种key的回收策略

默认情况下回收策略是noeviction（禁止收回）
/etc/redis/6379.conf配置文件中修改maxmemory-policy属性值
volatile-lru:使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰（建议使用）
volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru:使用LRU算法从所有数据集合中淘汰数据
allkeys-random:从数据集合中任意选择数据淘汰
no-enviction:禁止淘汰数据
去掉#注释后，配置文件一定要顶格写

redis-benchmark 测试工具

redis-benchmark是官方自带的redis性能测试工具，可以有效地测试redis服务的性能。基本的测试语法为redis-benchmark

-h：指定服务器主机名
-p：指定服务器端口
-s：指定服务器socket
-c：指定并发连接数
-n：指定请求数。
-d：以字节的形式指定SET/GET值的数据大小
-k：1=keep alive 0=reconnect
-r：SET/GET/INCR 使用随机key，SADD使用随机值
-P：通过管道传输<numreq>请求
-q：强制退出redis。仅显示query/sec值
--csv：以CSV格式输出
-l：生成循环，永久执行测试
-t：仅运行以逗号分割的测试命令列表
-I：Idle模式。仅打开N个idle连接并等待

结合上述选项，可以针对某台redis服务器进行性能测试，如执行redis-benchmark -h 20.0.0.11 -p 6379 -c 100 -n 100000命令即可向IP地址为20.0.0.11、端口为6379的redis服务器发送100个并发连接与100000个请求测试性能

[root@server1 redis]# redis-benchmark -h 20.0.0.11 -p 6379 -c 100 -n 100000 #redis压力测试 -c为并发量 -n为一共多少请求

[root@server1 redis]# redis-benchmark -h 20.0.0.11 -p 6379 -c 100 -q -d 100 #读取set、get大小，-q为强制退出 -d为多少字节
PING_INLINE: 185185.17 requests per second
PING_BULK: 179211.45 requests per second
SET: 183486.23 requests per second
GET: 180180.17 requests per second
INCR: 182481.77 requests per second
LPUSH: 191938.56 requests per second
RPUSH: 189393.94 requests per second
LPOP: 189035.92 requests per second
RPOP: 185185.17 requests per second
SADD: 183823.52 requests per second
HSET: 165016.50 requests per second
SPOP: 179533.22 requests per second
LPUSH (needed to benchmark LRANGE): 191204.59 requests per second
LRANGE_100 (first 100 elements): 76277.65 requests per second
LRANGE_300 (first 300 elements): 31897.93 requests per second
LRANGE_500 (first 450 elements): 20605.81 requests per second
LRANGE_600 (first 600 elements): 14703.72 requests per second
MSET (10 keys): 170068.03 requests per second

还可以测试某些操作的性能，例如执行redis-benchmark -t set,lpush -n 100000 -q 命令的作用是测试本机上redis服务在进行set与lpush操作时的性能

[root@server1 ~]# redis-benchmark -t set,lpush -n 100000 -q
SET: 187617.27 requests per second
LPUSH: 172711.58 requests per second