Redis

1. 数据结构
2. 缓存穿透、缓存击穿、缓存雪崩
3. 实现分布式互斥锁
4. RDB、AOF原理
5. 渐进式rehash
6. 跳跃表
7. 布隆过滤器
8. 哨兵模式、集群模式 
9. 脑裂问题

Redis数据类型

1. String
2. Hash
3. List
4. Set
5. Zset--使用跳表实现，时间复杂度为logn

缓存击穿、缓存穿透、缓存雪崩

缓存击穿--单个热点key失效，导致针对该key的请求直接打到数据库中；

解决办法：热点数据永不过期，加互斥锁

缓存穿透--请求不存在的key，访问直接到达数据库；

解决办法--缓存空值，布隆过滤器，业务参数合法性检验

缓存雪崩--大量热点key同时失效，导致大量请求落到数据库上

解决办法--热点数据永不过期，同一批热点数据失效时间加上随机值；

分布式互斥锁

SET key_name my_random_value NX PX 30000   

redlock原理--

1. 获取当前时间戳，并一次从各个主节点中获取锁
2. 要求获取锁的等待时间远小于锁的失效时间，这样某个节点获取失败之后及时从下一个节点获取，避免因单节点挂掉导致整个获取锁操作失败
3. 如果获取到大于一半节点的锁，并且此时锁未失效（锁的实际时间=设置的锁的有效时间-获取锁的时间）则加锁成功，
4. 获取锁失败后所有节点都会释放锁；
5. 推荐为奇数个节点的原因是防止两个进程各获取一半节点数，导致两个线程都加锁失败；

        redlock存在的问题--如果某个主节点宕机且没来得及将锁信息同步到从节点，导致后来的线程仍然可以加锁成功；

RDB，AOF原理

RDB--主进程fork出一个子进程，子进程与主进程共享内存（写时复制ROW）进行备份

写时复制技术：当RDB进行时候，如果对某个key进行修改，则主进程会将被修改key所在的页拷贝一份，然后对该拷贝的副本进行修改，RDB备份的任然是备份开始前的数据；RDB完成之后将该页替换回去；

也就是说在复制的时候会出现页面分离导致内存增长的情况；

AOF--命令记录，时间间隔一般为1秒一次，当AOF文件过大时会发生AOF文件重写；

AOF重写时如果发生数据修改，则将修改命令记录在aof_rewrite_buff中，当AOF重写完成之后才会追加到新的AOF文件中；

渐进式rehash

redis中使用链接法解决哈希碰撞--整个机制和JDK中的hashmap很像；

rehash在扩容和缩容的时候都会触发--Redis在少于10%的时候会触发缩容；

负载因子，redis中rehash是由主线程完成的，为了避免主线程阻塞时间过长，Redis每次在数据访问的时候进行rehash操作，并记录当前rehash的索引保持进度；

在rehash过程中数据修改操作会同时对ht[0]和ht[1]操作，保证数据一致性；