时间机制
文件事件
1. 为什么单线程的 Redis 能那么快？<br>
事件响应框架ae_event及文件事件处理器
Redis IO多路复用模型
aeEventLoop
创建事件管理器<br>
创建文件事件<br>
事件处理
删除事件<br>
高可用
主从复制
功能<br>
数据冗余
故障恢复
负载均衡
高可用基石
原理
全量复制<br>
第一阶段是主从库间建立连接、协商同步的过程
第二阶段，主库将所有数据同步给从库
第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库
增量复制
为什么会设计增量复制？<br>
流程
repl_backlog_buffer
replication buffer
如果在网络断开期间，repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制呢？<br>
为什么不持久化的主服务器自动重启非常危险呢？
为什么主从全量复制使用RDB而不使用AOF？<br>
为什么还有无磁盘复制模式？<br>
为什么还会有从库的从库的设计？<br>
读写分离及其中的问题<br>
延迟与不一致问题<br>
数据过期问题<br>
故障切换问题<br>
哨兵机制（Redis Sentinel）
功能
监控（Monitoring）
自动故障转移（Automatic failover）
配置提供者（Configuration provider）
通知（Notification）
集群的组建<br>
监控Redis库
集群的选举
为什么必然会出现选举/共识机制？<br>
哨兵的选举机制是什么样的？<br>
新主库的选出
故障的转移<br>
Redis集群(Redis Cluster)
Redis 集群的设计目标
Redis群集目标(Redis Cluster goals)<br>
Redis集群协议中的客户机和服务器角色(Clients and Servers roles in the Redis Cluster protocol)<br>
写入安全性(Write safety)<br>
主分区的master上，已经确认的写入在故障期间发生丢失
可用性(Availability)<br>
性能(Performance)<br>
避免合并(merge)操作<br>
主要模块
哈希槽(Hash Slot)
Keys hash tags<br>
Cluster nodes属性<br>
Cluster总线<br>
节点握手<br>
请求重定向<br>
Moved 重定向<br>
ASK 重定向<br>
smart客户端<br>
集群拓扑<br>
状态检测及维护<br>
Gossip协议<br>
Gossip协议的使用<br>
Meet
Ping
Pong
Fail
基于Gossip协议的故障检测<br>
自己保存信息
一起裁定
最终裁定
通讯状态和维护<br>
什么时候进行心跳？<br>
发送哪些心跳数据？<br>
Header
Gossip
如何处理心跳？<br>
新节点加入
Slots信息
Master slave信息
节点Fail探测(故障发现)
将信息广播给其它节点？<br>
故障恢复（Failover）<br>
扩容&缩容<br>
扩容<br>
缩容<br>
问题
为什么Redis Cluster的Hash Slot 是16384？<br>
为什么Redis Cluster中不建议使用发布订阅呢？<br>
其它常见方案<br>
Redis Sentinel 集群 + Keepalived/Haproxy<br>
Twemproxy
Codis
性能调优
经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令<br>
操作bigkey<br>
使用 O(N) 复杂度的命令，但 N 的值非常大<br>
集中过期<br>
为什么集中过期会导致 Redis 延迟变大？<br>
规避
实例内存达到上限<br>
如果此时你的 Redis 实例中还存储了 bigkey，那么在淘汰删除 bigkey 释放内存时，也会耗时比较久。
fork耗时严重<br>
开启内存大页<br>
开启AOF<br>
appendfsync always
appendfsync no
appendfsync everysec
网络带宽过载<br>
频繁短连接<br>
运维监控
其它程序争抢资源<br>
