Redis知识点梳理

脑裂问题（由于网络原因选举出两个master，此时client还在写一个老的master）

解决方案：

通过配置 min-slave-to-write  和 min-slave-max-lag 要求至少有一个slave复制和同步数据延迟不能超过10秒，就是说一旦所有slave复制数据都超过了10秒，整个时候master就不再接受请求了

（client 端可以通过降级或者将消息写到kafaka 然后每10秒拉去消息尝试重新写到master）

主从复制的完整流程：

1 slave node 启动 仅仅保存master node的信息 包括node的ip和host，但是复制流程还没开始。。

2 slave node 内部有个定时任务 每秒检查是否有新的master node 要连接和复制，如果发现 就跟master建立socket网络连接

3 slave node 发送ping命令给master

4 口令认证，如果master设置了requirepass,那么 slave node必须发送masterauth的口令进行认证

5 master 第一次执行全量复制 将所有数据发送给slave

6 master node 后续持续将写命令 异步复制给slave

backlog 

master node 有一个backlog ，默认大小时1M

master node 给slave复制数据时，也将数据在backlog中同步写一份

backlog 主要是用来做全量复制中断开网络情况乱下的增量复制的

哨兵的功能

（1）集群监控，负责监控redis master 和slave进程是否正常工作

（2）消息通知 如果某个redis实例有故障 那么哨兵负责发送消息作为报警通知给管理员

（3）故障转移 如果master挂掉了  会自动转移到slave上

（4）配置中心 如果故障转移发生了  通知client客户端新的master地址

master-slave 选举算法：

如果一个master被认为是主观down了 而且大部分的哨兵都允许了主备切换 那么某个哨兵就会执行主备切换 此时要考虑选出一个slave,

slave 会考虑如下信息：

（1）跟master 断开连接的时长

（2）slave 的优先级

（3）复制offset

  (4) run id

a 、如果slave 跟master断开连接已经超过了 down-after-milliseconds的十倍 那么就被认为不适合选举为master

b、 按照slave优先级排序  slave priority越低 优先级越高

c、如果slave priority相同 那么看offset，哪个slave 复制了越多的数据，offset约往后，优先级越高

AOF持久化

aof 是记录redis 写命令的 以append only 方式追加(其实是先写oscache 然后一般间隔1s 执行fsync到磁盘的)  但是因为redis 有缓存淘汰机制 ，aof到一定大时就会rewrite一份新的aof 然后删除原来的aof. 在redis 重启时 可以通过回放AOF日志中的写入指令来重新构建数据集

优点：

1 、AOF 可以更好的保护数据不丢失 一般aof会每间隔一秒通过后台线程执行一次fsync操作，做多丢失1秒的数据

2、AOF 日志是以append only 方式写入，所以没有任何磁盘寻址的开销

缺点：

1、 对于同一份数据来说 aof日志文件通常比rdb更大

2、aof 开启后 支持的写qps会比rdb低，因为aof一般会配置1s fsync一次

AOF持久化相关配置？

表示是否开启AOF持久化：
　　appendonly yes(默认no,关闭)
AOF持久化配置文件的名称：
　　appendfilename “appendonly.aof”
AOF持久化策略(默认每秒)：
　　appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
　　appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
　　appendfsync no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）
AOF的Rewrite(重写) ：
　　定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制
　　当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
　　　　　auto-aof-rewrite-percentage 100 （一倍）
　　　　 auto-aof-rewrite-min-size 64mb
　　　　
AOF配置文件损坏修复方法：
　　进入redis安装路径 执行 redis-check-aof –fix AOF配置文件名称

RDB 持久化

对redis 中的数据进行周期化的持久化。但是RDB 数据可能不是很完整（快照的概念）

优点：  （1）RDB 会生成多个文件 适合做冷备  

            （2）RDB对redis性能影响小，一般是fork一个子进程来操作RDB 

            （3）相对于AOF持久化机制来说，rdb来重启和回复redis更加快速（因为指令恢复慢些）

缺点：

         （1）如果想要丢失更少的数据，rdb没有aof好

         （2）rdb 每次fork子进程来执行快照文件时，如果文件特别大，可能会导致会让客户端提供的服务暂停数秒

redis 集群通信协议：

redis 节点之间通信是通过gossip 协议的，主要有四种消息：ping pong meet fail，

这种协议是通过每个节点自己本地维护一个完整的元数据（每个节点的元数据ip、主从等），然后有变化的时候在通知其他节点。

redis client 在维护hashslot和节点之间的关系映射表是通过本地缓存来存储的，避免各个节点之间的重定向

redis缓存雪崩（redis 宕机了，然后大量请求进来了）：

1 、 事前本地做ehcache 二级缓存

2、  事中限流+降级（部分请求可以处理，不能处理的请求可以友好提示 或者系统做补偿）

3、  事后利用redis持久化恢复数据

缓存穿透（大量请求进来了，但是有很多请求缓存中是没有的，可能时黑客攻击）：

解决方案：一般在数据库查不到就存一份null值进缓存 ，防止请求大量打到mysql

缓存击穿（大量请求进来了，但是缓存数据过期了）

缓存数据库不一致解决方案：

1、更新的时候，先删除缓存，在更新数据库。（但是在并发情况下还有不一致问题）

2、因为并发存在的问题，可以采取第二种方案：

库存服务可以设置一个队列，更新操作来了之后，先删除缓存完成后，直接将更新数据库消息丢到队列中，然后直接返回成功，下一个查询进来后缓存查不到直接进队列，排队来更新和查询数据库来保证数据一致。

3、可以设置合理的过期时间。接受一段时间的不一致

redis 的线程模型？

参考：https://www.cnblogs.com/volare/p/12283355.html

redis 为什么能支持高并发？

1、io多路复用只监听socket 是要监听到就压到队列，不处理

2、她处理请求是基于内存的

3、单线程反而避免了多线程上下文切换的开销

redis的过期删除策略？

1、定期抽取一些并删除

2、当你get的时候，主动检查 如果过期则删除

3、内存淘汰机制，LRU ,默认删除最近最少的key(当内存达到一个阈值时),还有其他一些删除策略

redis 底层数据结构？

https://blog.youkuaiyun.com/abel_liujinquan/article/details/89339599