Redis为什么用单线程模型
所有操作在内存，100ns
瓶颈不在cpu而是network IO，可以启动多实例提升cpu利用率
避免多线程上下文切换和竞争条件的开销，实现简单
单进程单线程模型
多路IO复用模块 + AeEventLoop
多路复用非租塞IO模型，Epoll监听多个socket，AE将连接、读、写、关闭都转化为事件，不在IO上浪费时间
main thread
执行客户端的命令请求
BIO background thread
耗时的操作，会放到后台线程中执行。如，文件句柄关闭任务；AOF持久化；空间懒释放
单线程模型存在问题：单条命令执行占用时间，造成阻塞
管道与事务
管道（pepiline）
一次性执行多条命令，并在执行完后一次性将结果返回客户端。减少客户端与redis的通信次数降低往返时间，提升性能。
如：mget,mset,hmget,hmset,rpush,lpush,sadd,zadd
事务（transaction）
执行事务过程，延迟执行已入列的命令直到客户端发送EXEC命令，大多redis客户端等事务包含的所有命令出现后，才一次性将multi命令，事务中要执行的命令以及exec全部发送给redis，等待回复。
Lua 脚本（没写过，不了解）
减少网络开销：将多个请求通过脚本的形式一次性发送，减少网络时延。
原子操作：中间不会被其他命令插入，作为一个整体执行，不存在竞态条件。
复用：脚本会保存在redis中，其他客户端可以复用。
持久化
Redis中数据存储模式有2种：cache-only,persistence;
cache-only即只做为“缓存”服务，不持久数据，数据在服务终止后将消失，此模式下也将不存在“数据恢复”的手段，是一种安全性低/效率高/容易扩展的方式；
persistence即为内存中的数据持久备份到磁盘文件，在服务重启后可以恢复，此模式下数据相对安全。
对于persistence持久化存储，Redis提供了两种持久化方法：
Redis DataBase(简称RDB)
Append-only file (简称AOF)
RDB概述（恢复快，数据丢失）
RDB是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
AOF概述（安全，性能慢）
类似binlog，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程
优点：可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。
缺点：AOF文件比RDB文件大，且恢复速度慢。
master通常使用AOF，slave使用snapshot，主要原因是master需要首先确保数据完整性
服务需要接收密集性的write操作，那么建议master采取snapshot，而slave采用AOF
过期策略
被动方式：客户端访问key时，发现key已过期，则进行删除key操作。
主动方式：客户端访问key时，发现key已过期，则进行删除key操作。若有些key可能永远也不会被访问到，又该如何处理呢？Redis会定期（每秒10次）从有过期时间的keys中随机测试一些keys，删除已过期的key。
1.随机取20%有设置过期时间的key
2.删除所有时间已经过期的key
3.如果删除的key占取出key的25%，则跳到第一步，循环执行
在复制链和AOF文件中如何处理过期keys
若key过期时，会在Slaves和AOF文件中同步一个DEL操作，以保证数据的一致性
过期删除操作仅在master实例上执行；
Slaves不能独立地过期keys，但会等待master发出的DEL；
Slaves的数据集中可能会存在过期的keys，但会根据其逻辑时钟来判断。若key过期时，会在Slaves和AOF文件中同步一个DEL操作，以保证数据的一致性。#redis新特性
