1.键过期清理策略：

1.定时清理：创建key的时候开启异步线程轮询，等时间到了之后清理key。
2.懒惰清理：不清理。查询的时候，判断key是否过期，如过期过滤结果并清除key。
3.定期清理：可自定义条件，例如30s内发生至少1000次变更，或者10s内发生至少100次变更，或1s内发生至少10次变更则遍历所有key清理过期数据。
默认懒惰清理+定期清理

2.持久化：

1.RDB持久化：

1.将所有key，value值保存在rdb文件中，redis启动是读取rdb文件载入内存。
2.save命令和bgSave。save有服务器进程直接操作保存操作，阻塞。
3.AOF文件更新频率比RDB高，如果服务器开启了AOF持久化，优先AOF。

2.AOF持久化：

1.保存所有的redis写命令。命令追加，文件写入，文件同步。命令先写入缓冲区，每隔一段时间或者缓冲区超过一定大小时fsync到磁盘。
2.重启节点时，生成伪客户端，发送redis命令初始化数据。
3.AOF时间久了，文件过大，需要重写。重写不需要分析原AOF文件合并命令，而是直接重新遍历内存数据，生成命令。BGReWrite。

3.集群间数据复制：

1.旧版复制：传输全量RDB文件，sync。
2.新版复制：初始化时传输全量RDB文件，当从节点断开连接恢复后，部分数据重同步psync。通过复制偏移量，复制积压缓冲区，服务器运行ID三部分来实现。

4.Sentinel

1.命令连接：向主服务器发送命令请求。INFO命令获取主节点信息以及所有从节点信息。PING命令判断各节点以及Sentinel是否在线，如果没有回复，则判断为该节点主观下线，询问其余Sentinel该节点是否下线，超过主观下线投票数之后，该节点客观下线，进行故障转接。
2.订阅连接：接受指定频道的消息，有点类似于mq。各个Sentinel之间通过向节点的sentinel:hello频道发送消息来互相通信。每个Sentinel都会给节点订阅发送消息，同时也会消费节点sentinel:hello频道的消息。

5.发布订阅

1.发布：publish。
2.订阅：subscribe
服务器中在pubsub_channels字典中维护所有channel频道与订阅节点的对应管理，例如 topic1 -> nodes[5].
在pubsub_patterns链表中保存所有模式与节点之间的对应关系。

6.事务

1.Multi开始事务标志，多个命令会加入到事务队列中，Exec统一执行。事务具有原子性，同个事务中的命令不会被其他命令截断。事务具有一致性，出错分为入队出错和执行出错，错误的命令不会入队，入队后所有的命令都会被执行，但是出错了不会回滚，会继续执行事务中的其他命令，redis作者认为执行出错一般出现在开发环境中，生产环境中比较少出现执行出错，为了追求简单高效的设计，没必要设置回滚。
2.Watch实现乐观锁。服务端维护Watched_keys字典。key是所有被监视的键，value是监视该键的所有客户端。先执行watch命令，在执行Multi命令，这个过程中有其他客户端修改了key对应的value值，会遍历监视该key对应的所有客户端，将Redis_Dirty_CAS标识打开，Exec命令执行前判断标识是否打开，打开则拒绝执行客户端提交的事务。