Redis相关知识点

Redis数据结构

String字符串
Hash
- 存储对象
List
- 微博关注列表、消息列表
- 双向链表，支持反向查找和遍历
- lrange命令支持从某个元素开始读取多少个元素，实现分页查询，基于Redis实现简单的高性能分页，性能高
Set
- 自动排重，很轻易实现交集、并集、差集的操作。比如共同关注，共同好友等功能
Sorted Set
- 排序的实现：增加了一个权重参数score，使集合中的元素能够按照score进行有序排列。比如直播列表中的礼物排行榜，在线用户列表等
- 保证增删改查的速度：SkipList 跳跃表
- 跳跃表数据结构：set集合中每个元素任意生成层数，每次增删改查都从第一层开始查询，查询到两数之间的时候调至下一层继续缩小范围，知道最后查询到具体数据或者最小区间

Redis做异步消息队列

Redis中的 list（列表）实现异步消息队列，使用rpush / lpush 操作插入队列消息，使用 lpop 和 rpop 来出队消息。使用场景：MQ任务过多时，把任务存在Redis，进行异步消费
队列空了怎么办？
- 队列空了，客户端不断pop，由于没有数据会不停地进行pop，这样的空轮询会占用CPU资源，redis的QPS被拉高，Redis慢查询可能会显著很多
- 解决方案：使用阻塞读：blpop，brpop。阻塞读在队列没有数据的时候会立即进入休眠状态，一旦有数据会立即醒来，消费延迟基本为零。
- 上面的方案中，如果阻塞时间过长，Redis客户端连接就成了闲置连接，闲置过久服务器会主动断开连接，减少闲置资源占用，这时候blpop，brpop就会抛出异常来。所以编写客户端消费者时需要注意捕捉异常，增加重试机制

Redis持久化

写时复制(copy on write)

在执行bgsave或bgrewriteaof命令时，Redis都会需要创建当前服务器的子进程，采用COW的方式来提高子进程使用效率。

原理

fork()出子进程共享父进程的物理空间，kernel将父进程所有内存页设置为read-only，当父进程(或者子进程)有内存写入操作时，read-only内存页发生中断，将触发中断操作的内存页复制一份(linux 单位内存页4KB)，父子进程各自持有独立的一份(其他部分还是父子进程共享)

优缺点

COW技术减少分配和复制大量资源时带来的瞬间延时
COW技术可减少不必要的资源分配。比如fork子进程时，父进程的代码段和只读数据段是不允许被修改的，就不需要复制

RDB和AOF

RDB

Redis DataBase 快照
Redis默认持久化方式
按照一定的时间将内存的数据以二进制文件的格式，快照的方式保存在硬盘中
配置文件中save参数定义快照周期：
- save 900 1
- save 300 10
- save 60 10000
优点：
- 只有一个文件dump.rdb方便持久化
- 容灾性好，保存在磁盘
- 性能最大化，fork子进程进行快照的写入操作，主进程继续处理命令，主进程不进行任何I/O操作，保证Redis高性能
- 数据集大时，启动效率比AOF高
缺点：
- 时效性不强，间隔一段时间进行持久化，容易造成数据丢失

AOF

append-only file 追加文件
将Redis执行的每次写命令记录到单独的日志文件，重启Redis会重新从持久化的日志文件恢复数据
两种持久化方式同时开启时，Redis优先选择AOF进行数据恢复
appendfsyncs设置写频率：
- appendfsync always
- appendfsync everysec（默认）
- appendfsync no
优点：
- 时效性强，数据安全
- 通过append模式写文件，数据丢失少
- AOF机制的rewrite模式。AOF文件没被rewrite之前，可以删除其中的某些命令
缺点：
- AOF文件比RDB文件大，恢复速度慢
- 数据集大时，启动效率比RDB低

Redis线程模型

基于Reactor模式开发的文件事件处理器：
- 多个套接字
- IO多路复用程序(epoll、线程与kernel内存共享空间mmap)
  - 文件事件分派器
  - 事件处理器
由于文件事件分派器队列消费是单线程，所以Redis被叫做单线程模型
利用I/O多路复用同时监听多个套接字，事件分派器根据套接字目前执行任务为套接字关联不同的事件处理器
由于使用I/O多路复用监听多个套接字，文件时间处理器既实现了高性能的网络通信模型，又很好地与Redis服务器中其他同样以单线程方式运行的模块进行对接，保持Redis内部单线程设计的简单性

Redis内存淘汰机制

先说下Redis过期策略：定时删除和被动删除

定期删除：每过100ms，Redis会随机去检查一些设置了过期时间的数据，如果过期就删除，之所以随机访问部分数据的原因是：大部分数据都设置了过期时间，如果每次都遍历去访问，会占用CPU，Redis没法保证高性能
被动删除：访问数据时会检查数据是否过期，如果过期就删除数据

但是如果有很多数据过期了，但是我们又没有去访问它，就会造成即使数据过期了，这些过期数据仍然堆积在内存，导致内存耗尽。这时候就需要Redis内存淘汰机制。

内存淘汰机制包括：

volatile-lru：从设置了过期时间的数据集中挑选最近最少使用的数据淘汰
volatile-ttl：从设置了过期时间的数据集中挑选即将过期的数据淘汰
volatile-random：从设置了过期时间的数据集中随机选择数据淘汰
volatile-lfu：从设置了过期时间的数据集中挑选最少使用的数据淘汰
allkeys-lru：从所有数据集中挑选最近最少使用的数据淘汰
allkeys-lfu：从所有数据集中挑选最少使用的数据淘汰
allkeys-random：从所有数据集中随机选择数据淘汰
no-eviction：禁止驱逐数据，当内存不足以容纳新写入的数据时，新写入操作报错

Redis并发竞争问题

Redis本身是单线程模型，不存在并发问题，但是我们使用jedis等客户端对Redis进行并发访问的时候，就存在并发竞争的问题
使用Redis分布式锁。Redis分布锁实现主要是利用redis的SETNX。无论是哪种分布式锁基本原理都是不变的，都是通过数据携带一个标识，根据标识的状态来判断是否获取到锁
消息队列。并发量过大的情况可以使用消息中间件，将Redis.set操作放在队列中一个一个执行

Redis分布式锁

手写实现简易的乐观锁实现(项目里有实现)
基于Redisson实现
基于Zookeeper实现

Redisson

redisson具体执行加锁逻辑都是通过lua脚本完成的，lua脚本能够保证原子性。

RLock lock = redisson.getLock("anyLock");

lock.lock();
lock.unlock();

可重入锁
watchDog原理：当线程A拿到锁，线程A锁超时释放，但是线程A的业务还没有执行完；这时候线程B拿到锁，执行自己的业务，这样分布式锁就没有意义了。Redisson引入watch dog的概念，当线程拿到锁，会有一个后台线程自动延长锁的过期时间，防止业务没执行完而锁过期的情况。

Zookeeper分布式锁

线程每次在zookeeper中争抢锁，只有一个能获得锁
使用Zookeeper临时节点(session)，临时节点当客户端连接中断，存活时间耗完就自动删除。这样可以防止获得锁的客户端出现问题而导致死锁。
sequence(序列节点) + zk的watch机制：多个线程竞争时，按序列依次watch前一个线程，最小序列获得锁，释放后给后一个节点发事件回调，后一个节点尝试获得锁。这样限制了Redis并发竞争的问题，资源消耗压力也小。

Redis事务

Redis事务通过MULTI,WATCH,EXEC,DISCARD四个原语实现
- WATCH命令是一个乐观锁，可以监控一个或者多个key，一旦其中一个key被修改(或删除)，之后的事务不执行，监控一直持续EXEC命令被执行。
- MULTI用于开启一个事务，总是返回OK。MULTI之后客户端可以向服务器发送任意多条命令放在一个队列中，当EXEC命令被调用时所有队列的命令才能执行。
- EXEC：执行所有事务块内的命令，命令按队列先后顺序排列。
- DISCARD：清空事务队列，退出事务。
事务隔离，多个线程进入，谁先执行EXEC命令就先执行谁，排他性。
Redis事务不支持回滚。有命令执行失败则继续执行之后的命令，保证Redis内部简单且快速(性能为王）。
Redis命令有错误，则所有命令都不执行；命令出现运行错误，继续执行之后的命令。
Redis满足ACID的一致性和隔离性(事务管理ACID：Atomicity 原子性；Consistency 一致性；Isolation 隔离性； Durability 持久性)

Redis主从复制

Redis主从复制，一主多从，读写分离。主节点负责写操作，并将数据复制到其他slave节点，从节点负责读。所有读请求全部走从节点，支撑读高并发。

复制模式

全量复制：Master全部同步到Slave
部分复制：Slave数据丢失进行备份

Redis主从复制核心原理

当开启一个slave node时，它会发送一个PSYNC命令给master node
如果是slave node初次连接到master node，则触发一次全量复制(full resynchronization)。此时master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端client新收到的所有写命令缓存在内存中。
RDB文件生成完毕后，master会将这个RDB文件发送给slave，slave先写入本地磁盘，在从本地磁盘加载到内存中
然后master会将内存中缓存的写命令发送到slave，slave也会同步这些数据
slave节点如果和master节点有网络故障，断开连接后会自动重连，重连后master节点只会复制给slave部分缺少的数据(部分复制)

过程原理

当主从库建立MS关系后，slave会向master发送SYNC命令
master库接受到SYNC命令后，就开始在后台保存RDB快照，并将期间接收的写命令缓存起来
当快照完成，master会将快照文件和所有缓存的写命令发送给slave
slave接收到后，会载入快照文件并执行收到的缓存的写命令
之后，master每当接受到写命令都会将命令发送给slave，从而保证数据一致

主从配置不一样会有什么问题

maxmemory不一致：数据丢失
优化参数不一致：内存不一致

缺点

所有slave节点数据的复制和同步都有master节点处理，master节点压力过大。

哨兵模式

哨兵模式用于监控Redis主从节点，实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

节点下线

主观下线：Sentinel集群每一个节点会定时对Redis集群的所有节点发送心跳包检测节点是否正常，如果节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Sentinel节点就会认为这个Redis节点下线
客观下线：所有Sentinel节点对Redis节点失败要达成共识，即超过quorum数量的Sentinel都认为该Redis节点主观下线，Redis才真正被认为下线

Leader选举

选举一个Sentinel作为Leader：集群中至少要有三个Sentinel节点，但只有Leader Sentinel 节点才能完成故障转移
选举流程
- 每个主观下线的Sentinel节点向其他Sentinel节点发送命令，要求设置自己为领导者
- 收到命令的Sentinel节点如果没有同意其他Sentinel节点发送的命令，则同意该请求，否则拒绝
- 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum，则它成为领导者
- 如果在这个过程中有多个Sentinel节点成为领导者，则等待一段时间再重新选举

故障转移

选举出的Leader Sentinel进行故障转移；Sentinel集群运作过程中故障转移完成，所有Sentinel又会恢复平等。Leader仅仅是故障转移操作出现的角色
转移流程
- Sentinel选出一个合适的Slave节点作为新的Master
- 向其余Slave发出通知，让它们成为新Master的Slave
- 等待旧Master复活，并使之成为新Master的Slave
- 向客户端通知Master变化
选择新Master节点的规则：
- 选择slave-priority最高的节点
- 选择复制偏移量最大的节点(同步数据最多)
- 选择runId最小的节点
定时任务
- 每1s每个Sentinel对其他Sentinel和Redis节点执行ping，进行心跳检测
- 每2s每个Sentinel通过Master的Channel交换信息(pub-sub)
- 每10s每个Sentinel对Master和Slave执行info，目的是发现Slave节点，确定主从关系
缺点
- 主从服务器的数据要经常进行主从复制，性能受影响
- 当主服务器宕机，Slave节点切换成Master节点那段时间，服务不可用

一致性Hash

如果直接使用Hash算法 hash(key) % length，当缓存服务器变化时(宕机或新增节点)，length字段发送变化，就会导致所有缓存数据都要重新进行Hash运算，原来的数据就访问不到了，大量数据请求容易导致服务器雪崩，因此，引入一致性Hash
一致性哈希：通过对2^32取模来计算Hash值，保证增删缓存服务器时数据不变。
将2^32想象成一个环，一致性哈希算法通过将缓存服务器和被缓存对象都映射到Hash环上以后，从被缓存对象的位置出发，沿顺时针方向遇到的第一个服务器就是当前对象将被缓存的服务器，由于被缓存对象和服务器Hash后的值固定，所以在服务器不变的情况下，一个对象必定缓存在一个固定的服务器上。
Hash环偏斜问题：
将现有的物理节点通过虚拟的方法复制出来，而复制出来的节点被称为"虚拟节点"，让服务器尽量多的，均匀的出现在Hash环（注意Hash环是一个虚拟出来的模型，方便理解，不是真实的）
一致性Hash解决容灾问题：
如果其中一个节点宕机了，其他服务器的对象仍然能被命中，因为对象的映射到服务器的位置已经固定了，不会因为服务器宕机而导致独享找不到，宕机的服务器上的对象会在下次容灾分配时，重新分配到就近的服务器上

缓存策略

更新策略

allkeys-lru、volatile-lru 最近最少

缓存最终一致性

读请求：先读缓存，缓存没有就读数据库，取出数据放入缓存，同时返回响应
写请求：先更新数据库，然后再删除缓存(直接删除缓存的原因：1.是为了避免大量写而不经常读的情况，造成冷数据过多，导致缓存频繁更新 2.两个线程同时进行更新操作，线程A先更新了数据库，线程B后更新数据库，但是由于一些原因导致线程B比线程A先更新了缓存，导致了脏数据。所以直接删除缓存是最好的)


*   应用直接写数据到数据库中
    
*   数据库更新binlog日志
    
*   利用Canal中间件读取binlog，并借助限流组件按频率将数据发到MQ
    
*   应用监控MQ通道，将MQ的数据更新到Redis缓存中

缓存穿透

当大量请求没有命中缓存(代码bug，恶意攻击，高并发)，直接请求到后端数据库，无法利用缓存，流量过大而导致数据库压力过大
解决方案：采用布隆过滤器，redis继承了一个bloomFilter
过滤原理：
- 准备一个bit数组，用于存放Hash值
- 准备n个映射函数(输入：redis的key值和salt；输出：int类型的hash值)
- 每次有新key进入redis，都用这n个映射函数对key计算hash值，计算出来的值对应bit数组上的位置设置为1
- 当有新的查询时，将需要查询的key通过这n个映射函数求取hash值，如果这些hash值对应bit数组的位数都为1，则说明这个key"可能"在缓存中，让它先走缓存查找；如果有一个hash值对应位数为0，则说明这个key一定不在缓存中，直接走数据库查找。

缓存雪崩

一时间大量缓存失效或者缓存崩溃，请求直接落在数据库上，很可能由于无法承受大量的并发请求导致数据库崩溃
应对方案
- 事前：Redis主从复制+哨兵模式，Redis Cluster，保证高可用避免崩盘
- 事中：增加本地ehcache缓存+hystrix限流&降级，避免数据库承受太多压力
- 事后：Redis持久化(RDB,AOF)，一旦重启，自动从磁盘上加载数据，快速回复缓存数据
请求过程
- 用户请求的时候先访问本地缓存，没有命中本地缓存再访问Redis，如果还有没有命中Redis缓存，再查询数据库，并把数据添加到Redis和本地缓存中
- 设置了限流，一段时间内超出的请求走降级处理(hystrix支持自己定义降级方法，返回默认值或者给出友情提示就好了)