单线程和高性能
数据都在内存中，运算基于内存而不是磁盘，快速；
单线程，避免了多线程频繁切换带来的性能损耗；
单线程如何处理高并发连接：
多路复用：利用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