Redis配置优化

Redis配置文件

配置参数(/etclredis/6379.conf)

bind:监听的主机地址
port:端口
daemonize yes:启用守护进程
pidfile:指定PID文件
loglevel notice:日志级别
logfile:指定日志文件

Redis数据库常用命令

redis-cli命令行工具
连接本地数据库

/usr/local/redis/bin/redis-cli
127.0.0.1:6379>

连接远程数据库

redis-cli -h 192.168.10.161 -p 6379
192.168.10.161>

Redis命令工具

redis-server    ：用于启动Redis的工具
redis-benchmark ：用于检测Redis在本机的运行效率
redis-check-aof ：修复AOF持久化文件
redis-check-rdb ：修复RDB持久化文件
redis-cli       ：是Redis命令行工具 
redis-sentinel  ：是哨兵模式启动的工具

Redis-benchmark 测试工具

基本测试语法为redis-benchmark [option] [option value]

-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-benchmark -h 192.168.1.10 -p 6379 -c 100 -n 10000
redis-benchmark -h 192.168.1.10 -p 6379 -q -d 100
redis-benchmark -t set,lpush -n 100000 -q

Redis多数据库操作

Redis支持多数据库，默认支持16个数据库，0-15命名
多数据库相互独立，互不干扰
多数据库常用命令

多数据库间切换
多数据库间移动数据
清除数据库内数据

Redis数据库常用命令

key相关命令

keys：获取符合规则的键值列表
exists：判断键值是否存在
del：删除当前数据库的指定key
type：获取key对应的value值类型
rename（覆盖）/renamenx(不覆盖)：对已有的key进行重命名
dbsize：查看当前数据库中key的数目

[root@localhost	~]# redis-cli     连接数据库
127.0.0.1:6379> keys s*         获取s开头的键值并显示
1) "set1"
127.0.0.1:6379> exists set1     判断键值set1是否存在，存在输出返回1
(integer) 1
127.0.0.1:6379> exists set2     判断键值set2是否存在，不存在输出返回0  
(integer) 0

127.0.0.1:6379> keys *      列出key中的所有关键词
127.0.0.1:6379> del set1     删除set1关键词，操作成功输出1
127.0.0.1:6379> exists set1  查询set1键值是否存在，不存在输出返回0  
127.0.0.1:6379> type chen   获取hash1对应的vlane值类
127.0.0.1:6379> type set2    获取set2对应的vlane值类型

Redis持久化

持久化概述

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

持久化分类

RDB方式:创建快照的方式获取某一时刻Redis中所有数据的副本
AOF方式:将执行的写命令写到文件的末尾，以日志的方式来记录数据的变化

二者区别

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

二者优缺点

RDB存在的优势

一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB存在的劣势

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF存在的优势

该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF存在的劣势

对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

通过RDB文件恢复数据

vi letc/redis/6379.conf
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis/6379
rdbcompression yes
900秒之内至少—次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作，只要满足其一都会触发快照操作，注释所有的save项表示关闭RDB

AOF持久化

Redis默认不开启
弥补RDB的不足（数据的不一致性)
采用日志的形式来记录每个写操作,并追加到文件中
Redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

vi /etc/redis/6379.conf
appendonly yes         #开启 AOF持久化
appendfsync always

/etc/init.d/redis_6379 restart
cd /var/lib/redis/6379/
ll

AOF的重写机制

AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多
当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩

AOF重写的原理

Redis会fork出一条新进程，读取内存中的数据（并没有读取旧文件)，并重新写到一个临时文件中，最后替换旧的aof文件

Redis性能管理

查看Redis内存使用

[root@localhost ~]# /usr/local/redis/bin/redis-cli 
127.0.0.1:6379> INFO memory

内存碎片率

操系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出
内存碎片是由操作系统低效的分配/回收物理内存导致的

不连续的物理内存分配

跟踪内存碎片率对理解Redis实例的资源性能是非常重要的

内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换

内存使用率

Redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换
避免内存交换

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

回收Key

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

默认情况下回收策略是禁止删除
redis.conf配置文件中修改 maxmemory-policy属性值
volatile-lru:使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random:从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru:使用L RU算法从所有数据集合中淘汰数据
alkeys-random:从数据集合中任意选择数据淘汰
 no-enviction: 禁止淘汰数据

配置文件
vi /etc/redis/6379.conf
# maxmemory-policy noeviction                   #修改
maxmemory-policy volatile-lru
/etc/init.d/redis_6379 restart