redis-核心原理

单线程和高性能

数据都在内存中，运算基于内存而不是磁盘，快速；

单线程，避免了多线程频繁切换带来的性能损耗；

单线程如何处理高并发连接：

　　多路复用：利用epoll来实现io多路复用。

多路复用

 

注意点：

1.尽量避免使用key命令。比如redis存有上百万条数据，redis读取一般10w/s，起码也要运行10s去执行key命令，其他客户端都要等10s;

2.大容量value的数据最好不要存放在redis里，获取时间长，造成其他命令的阻塞；

持久化

RDB快照

文件存储：

　　默认情况下，redis将内存数据库快照保存在dump.rdb文件中。

配置：redis.conf中配置，save参数定义了when做数据备份

　　例：save 60 1000 表示60s内有1000次修改，会对整个内存进行一次数据备份。

存在的问题：

　　若60s内只做了999次修改，就不会对数据做备份，此时若宕机，数据就会丢失。

AOF(append-only file)

文件存储：

　　数据保存在appendonly.aof文件中。

配置：

　　appendonly yes（开启aof）

　　appendfsync everysec（官方推荐设置）

　　当执行一个数据修改的命令时，这个命令会存到aof文件中，当redis重启后，会全部执行一次aof文件中的命令，保证宕机造成的数据丢失。

存在的问题：

　　当更新很多时，redis启动会很缓慢，需要将aof中的命令全部执行一遍。

混合持久化

AOF重写：

　　对一个key只记一条命令（汇总的）

　　重写AOF文件命令：bgrewrite aof

文件存储：

　　数据保存在appendonly.aof文件中，不过这个文件包含两种格式的数据：RDB格式、AOF格式

配置：

　　appendonly yes

　　aof-user-rdb-preamble yes （混合模式是基于aof的，所以两个要同时开启）

　　auto-aof-rewrite-* （重写规则）

原理说明：

　　配置定时重写规则，或者手动触发重写

　　重写时，会将数据以RDB格式保存到aof的前半部分，重写期间，若有新的修改，会将新修改的记录以AOF格式放到aof的后半部分。

　　总结：AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

缓存淘汰策略

当redis内存超出物理内存限制时，内存的数据会开始和磁盘发生频繁的交换，性能下降。

为避免redis发生交换，所以我们需要配置允许的最大内存，同时选择淘汰策略。

配置：redis.conf

　　maxmemory <bytes> 最多存多大的数据

　　maxmemory-policy

　　　　noeviction  默认。不再服务写请求(delete可以)，读请求可以

　　　　volatile-lru  尝试淘汰设置了过期时间的key，最少使用优先淘汰。

　　　　volatile-ttl

　　　　volatile-random

　　　　alikeys-lru  淘汰全体key集合

　　　　alikeys-random