redis 快速总结
为什么快
- io多路复用：一个线程监听多个客户端网络io
- 单线程：减少上下文切换
- 基于内存
- epoll
线程io模型
redis是不是单线程
6.0以前内存数据处理和网络io读写都是单线程（主线程），不过AOF和主从同步是其他线程。
6.0后支持的I/O多线程特性，默认情况下I/O多线程只针对发送响应数据，并不会以多线程的方式处理读请求。
要想开启多线程处理客户端读请求，就需要把Redis.conf配置文件中的io-threads-do-reads配置项设为yes。这样有效提高客户端的读取请求井发。
6.0后的变化
- 提供了众多的新模块 api
- 提供了客户端缓存功能
- 多线程网络I/O能力
- 提升了RDB日志的加载速度
持久化机制
AOF 增量备份
优点：根据不同的fsync策略可以保证数据丢失风险降到最低，数据能够保证是最新的。fsync是后台线程在处理，所以对于处理客户端请求的线程并不影响。
缺点：文件体积由于保存的是所有命令会比RDB大上很多，而且数据恢复时也需要重新执行指令，在重启时恢复数据的时间往往会慢很多。虽然fsync井不是共用处理客户端请求线程的资源来处理的，但是这两个线程还是在共享同一台机器的资源，所以在高井发场景下也会一定受到影响。
如果增量备份时，文件太大怎么办？ aof重写
RDB 全量备份
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了Redis的高性能；而且RDB文件存储的是压缩的二进制文件，适用于备份、全量复制，可用于灾难备份，同时RDB文件的加载速度远超于AOF文件。
缺点：RDB是间隔一段时间进行持久化，如果持久化之间的时间内发生故障，会出现数据丢失。
AOF和RDB混合持久化
过期删除机制
定时删除
每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性删除
只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
定期删除
每隔一段时间就对一些键进行检查，删除其中过期的键(周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度)。该策路是情性删除和定时删除的一个折中，既避免了占用大量CPU资源又避免了出现大量过期键不被清除占用内存的情况。
redis策略
惰性删除+定期删除
内存淘汰策略
事务机制
基于lua脚本
集群策略
架构
一般都是三主三从架构
中小型公司 一台redis或者两台机器主从，业务线不用划分