需求：MySQL面临大量的查询，即读写操作，因此类比CPU，给数据加缓存，Redis诞生。应用程序从MySQL查询的数据，在Redis设置缓存（记录在内存中，无需IO操作），后再需要可查询缓存。
内存满了怎么办？
定期删除：给缓存内容设置超时时间，删除随机算法选择的部分过期内容。
惰性删除：逃脱随机算法的过期键值数据，遇到查询请求即删除。
内存淘汰策略：仍然内存不足后的方法
常见的三种问题&应对方式
缓存穿透：查询数据不存在，绕过redis持续读写操作。
缓存击穿：热点数据被删除，大量请求到mysql。
缓存雪崩：大量数据过期删除，mysql崩溃。
缓存击穿&缓存雪崩应对方式：过期时间分布均匀 + 热点数据永不过期
缓存穿透应对方式：布隆过滤器Bloom filter
· 是基于哈希算法和位数组的，节省空间的概率数据结构
· 用于回答这个元素是否在集合中？会给出肯定的否或可能的是的回答，可能误报存在，不可能漏报-不存在一定不存在
持久化存储机制
需求：redis崩溃导致数据丢失，需提前在硬件上做持久化存储。
RDB二进制文件：按配置参数周期性备份，但是分钟级备份不能应对毫秒级请求需求，参考mysql的binlog操作命令日志，AOF持久化诞生。
AOF(Append Only File)持久化：redis命令日志文件
· 若没执行一个操作就写入硬盘中文件会严重影响性能，因此创建临时缓冲区aof_buf；
· 备份文件过大，因此出现AOF重写机制，指令合并
· 子进程重写过程中修改数据导致数据不一致，因此创建aof_rewrite_buf，存放子进程重写期间redis写入命令，子进程重写后再据此补充aof文件，替换原文件
哨兵与高可用原理
需求：通过主从复制达到高可用-减少服务不可用的时间
主节点：负责数据写入和同步（RDB文件+命令传播），复制积压缓冲区（同步给从节点的时候同时写入缓冲区以作备份）
从节点：同主节点一样，根据游标偏移量比较缺失数据内容
多个哨兵sentinel负责统筹协调，谁要是掉线了，可以选一个从节点顶上，无需程序员主动将从节点设为主节点。
· 哨兵每隔10s用info命令问候主节点，获取从节点信息；每隔1s用ping命令问候各节点看是否在线
· 哨兵发现主节点掉线为主观下线，按配置多个哨兵发现则为客观下线
故障转移：选择新的主节点，让其他从节点从新的主节点同步数据，把原来旧的主节点改成从节点
新主节点选择标准：优先级越高（如高配置）、断开主节点时间越短、复制偏移量越大
Redis集群机制
需求：提升数据容量
通过三次握手加入集群（参考TCP三次握手）
数据存储分配（参考哈希表）：16384个哈希桶/槽位Slot，程序员按内存分配。
· 数据读写时，对键值进行哈希计算/槽位计算
· 互相知晓槽位信息，么个槽位用一个bit表示，自己负责的是1，否则0，总过2048字节
· struct clusterNode *slots[16384 / 8]额外超大数组存储每个槽由哪个节点负责
· 所有的槽位均有节点负责才是集群上线状态，否则是下线状态