Redis 学习框架
高性能：线程模型、数据结构、持久化、网络模型
高可靠：主从复制、哨兵机制
高可扩展：数据分片、负载均衡
线程模型
单线程模型：Redis的网路IO 和 数据读写是由同一个线程来完成的
Redis 为什么不使用多线程？
多线程的优势：由于CPU与IO的读写速度差异巨大导致CPU空闲，利用多线程分时复用CPU资源可以提高吞吐率；多线程的劣势：多线程模式面临的共享资源的并发访问控制问题，增加了复杂度，降低了可维护性
因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。
单线程 Redis 为什么那么快？
1. Redis 大部分操作是在内存上完成，并且采用了高效的数据结构如哈希表和跳表
2. Redis IO 多路复用机制：Redis 网络框架调用 epoll 机制，让内核监听多个监听套接字和多个已连接套接字 。select/epoll 提供了基于事件的回调机制，一旦监测到 FD 上有请求到达时，就会触发相应的事件。 这些事件会被放进一个事件队列，Redis 单线程对该事件队列不断进行处理，调用相应的处理函数，从而实现高吞吐率
Redis单线程处理IO请求的性能瓶颈
1、单个请求非常耗时。耗时的操作包括以下几种：
a、操作bigkey：写入bigkey时分配内存需要消耗的时间，删除bigkey释放内存同样会产生耗时
b、使用复杂度过高的命令：例如SORT/SUNION/ZUNIONSTORE，或者O(N)命令，但是N很大，例如lrange key 0 -1一次查询全量数据；
c、大量key集中过期：Redis的过期机制也是在主线程中执行的，大量key集中过期会导致处理一个请求时，耗时都在删除过期key，耗时变长；
d、淘汰策略：淘汰策略也是在主线程执行的，当内存超过Redis内存上限后，每次写入都需要淘汰一些key，也会造成耗时变长；
e、AOF刷盘开启always机制：每次写入都需要把这个操作刷到磁盘，写磁盘的速度远比写内存慢，会拖慢Redis的性能；
f、主从全量同步生成RDB：虽然采用fork子进程生成数据快照，但fork这一瞬间也是会阻塞整个线程的，实例越大，阻塞时间越久；
2、并发量非常大时，单线程读写客户端IO数据存在性能瓶颈，虽然采用IO多路复用机制，但是读写客户端数据依旧是同步IO，只能单线程依次读取客户端的数据，无法利用到CPU多核。
针对问题1，一方面需要业务人员去规避，一方面Redis在4.0推出了lazy-free机制，把bigkey释放内存的耗时操作放在了异步线程中执行，降低对主线程的影响。
针对问题2，Redis在6.0推出了多线程，可以在高并发场景下利用CPU多核多线程读写客户端数据，进一步提升server性能，当然，只是针对客户端的读写是并行的，每个命令的真正操作依旧是单线程的。
数据结构
Redis 通过全局哈希表来保存所有的键值对，让我们可以用 O(1) 的时间复杂度来快速查找到键值对。
哈希冲突和Rehash
五种数据类型（String、Hash、List、Set、Sorted Set）对应的数据结构
持久化
AOF 写后日志
优势：避免记录错误命令、不会阻塞当前的写操作
劣势：可能丢失数据、阻塞后续的操作
三种写回策略
Always：同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
AOF 重写机制
主线程fork出后台bgrewriteaof子进程，fork采用操作系统的写时复制（Copy On Write）机制避免了拷贝大量的内存数据，bgrewriteaof子进程在不影响主线程的情况下，逐一将内存数据写入重写日志。重写过程中主线程并不阻塞，仍然可以处理新来的操作。如果有写操作，Redis 会把这个操作写到老的AOF缓冲区，保证AOF 日志齐全，同时这个操作也会被写到重写日志的缓冲区，等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件
AOF 重写阻塞点
1、fork子进程：实例越大，内存页表越大，fork阻塞时间越久
2、AOF重写过程中父进程产生写入：写时复制bigkey、Huge Page
主从复制
Redis 采用主从读写分离方式来避免数据竞争带来的开销
同步过程
1. 建立连接，协商同步 psaync
2. 主库同步数据给从库 发送RDB文件
3. 全量复制完成后，主从之间会一直维护一个网络连接，主库同步新写的命令给从库 发送repl buffer
通过主从级联模式可以分担主库生成和传输RDB文件的压力
哨兵机制
在主从集群中，当主库发生故障时，哨兵机制可以实现主从自动切换
哨兵机制的流程
1. 监控：哨兵定时给所有主从库发送PING命令，如果主从库中规定时间（）内响应，哨兵就回将该从库标记为【下线状态】，如果主库下线，就回开始主从自动切换
2. 选主：哨兵通过“筛选 + 打分”的方式进行选主，筛选主要判断从库的当前在线状态（断连时间：down-after-milliseconds）和之前的网络连接状态（断连次数），打分分别是优先级（slave-priority）、从库复制进度（master-repl-offset - slave-repl-offset）和从库ID号（兜底）
3. 通知：通知其他从库，让他们执行replicaof，和主库建立连接，同步数据；同时将新主库的连接信息发送给客户端，客服端会把请求发送到新主库上
哨兵监控过程产生误判的原因：集群网路压力大，网路阻塞，主库本身压力大
哨兵集群