Redis核心技术与实战
rehash
·装载因子（entry个数 除以 hash桶个数）
渐进式rehash
·每处理一个请求拷贝一次; 同时也会有定时任务执行rehash，在没有键值对操作时周期性迁移
跳跃表
·在链表的基础上增加了多级索引，数据比较大的时候时间复杂度o(logN)
压缩列表
·类似数组，但在表头有3个字段分别表示列表长度、列表尾的偏移量、列表中entry的个数；表尾还有一个标识表示列表结束，时间复杂度o(N)
redis为什么那么快
·大部分操作在内存完成、高效地数据结构（例如hash表和跳跃表）、多路复用机制
扩展redolog
·记录的是修改后的数据
AOF
·先执行命令再记日志
·记录的是redis收到的每一条命令
·一个拷贝两处日志
·fork瞬间会阻塞主进程（拷贝内存页表，消耗cpu）
·fork写实复制（写已经存在的key时，父进程会拷贝这个key的内存数据，申请新的空间，消耗内存）
RDB
·全量快照
·bgsave
·fork写实复制
·经过压缩的二进制数据
主从同步
·全量复制
建立连接，协商同步、主库发送RDB文件给从库、主库发送(replication buffer中)新写命令给从库
·主从级联模式分担全量复制主库压力，主-从-从模式（基于长连接的命令传播）
·增量复制
网络断联中的增量复制，环形缓冲区，repl_backlog_size大小很重要，太小可能会导致主库每次 都全量复制
哨兵机制
·监控、选主、通知从库与客户端
·哨兵集群共同决定减少误判
·如何选新主库，筛选+三轮打分
筛选：去除掉不在线 或网络状态不好的从库
三轮打分：从库优先级 、从库复制进度 、从库ID号，有一轮中有最高就结束
·主从切换过程中，客户端是否能正常请求
·哨兵领导者选举，类似Raft共识算法，随机时间，请求其他哨兵为自己投票
·基于redis提供的发布订阅机制相互发现，在主库上发布消息，从主库订阅消息
·哨兵是如何知道从库的地址的？通过向主库发布INFO命令获取从库列表
·客户端与哨兵通信，基于客户端从哨兵订阅消息
切片集群
·官方提供了Redis Cluster方案，用于实现切片集群
·Redis Cluster 方案
·16384个哈希槽
· Redis实例间相互连接通信，把自己的哈希槽信息发给其他实例
·客户端收到实例信息后会缓存一份在本地
·重定向机制，MOVED（已经迁移，客户端会更新本地缓存），ASK(正在迁移，不会更新本地缓存，只是当前key去新的实例请求)
