redis知识体系

redis是我们平时项目中经常接触到的重要的中间件之一，在很多场景下均有应用。平时没有时间总结，现在趁着有点时间总结下redis的一些知识
一、redis的基本概念
redis是一种基于内存高速缓存的数据库，存储的数据结构是key-value类型，可以应用在缓存、分布式锁、消息队列、以及计数器、存储token等场景。
二、redis的数据类型
对于redis基础的也是常有的数据类型用以下5种：string、hash、list、set、zset
三、应用场景
上面聊过了redis的基础知识，下面结合使用场景聊下redis常见的问题和解决方法
1、缓存
redis做为缓存时，一般请求会先到redis，redis中有数据时，会返回redis中的数据，redis没有时，会请求数据库中的数据，redis中也没有数据时返回为空，如果存在数据时，数据会同步到redis中同时返回查询到的数据。如下图：

redis作为缓存使用时避免不了几个概念：缓存穿透、缓存击穿、缓存雪崩
**缓存穿透：**更多的发生在恶意访问，大量请求访问redis和数据库中均不存在的数据，造成请求直接请求到数据库。
解决方法：
1、缓存null值。 当查询到数据库中数据为null时，将null也缓存到redis中。
存在的问题：这样处理可能会带来数据不一致的问题，因为某种原因下数据库数据没有及时更新，这个时候访问数据库数据为空，null同步到redis后数据库中数据正确更新，这样就造成数据不一致的情况出现
2、布隆过滤器。在数据写入数据库的同时将这个 ID 同步到到布隆过滤器中，在查询redis前先访问布隆过滤器判断数据是否存在，不存在时直接返回数据不存在

如下图我们一起看下布隆过滤器的原理吧，取不同id1、id2三个不同的hash值，存入bigmap中，在查询数据时，会判断id的三个hash值是否存在，如果存在就任务这个这个数据已经存在，反之不存在。但是如下图id3的三个hash值并不属于一个id的（两个hash值属于id2、一个hash值属于id1），程序也会认为数据已经存在，所以布隆过滤器也会存在误判的情况

存在的问题：布隆过滤器会存在精度的问题，可能会存在误判的情况。
综上所属，对于缓存穿透这种情况两种处理方法均有不足之处，但是综合来看控制好布隆过滤器的精度，布隆过滤器还是更能解决这个问题。
**缓存击穿：**某一个热点key，在过期和redis中数据重建的这个时间期间大量的请求直接访问数据库，对数据库产生较大的压力

解决方法：1、添加互斥锁，原理如下图
存在的问题：由于多个线程需要等待锁的释放，所有性能会差些，但是能够保证数据的一致性
2、逻辑过期

存在问题：能够保证性能，但是不能保证数据的一致性
**缓存雪崩：**大量的key，某一时刻同时过期或者redis宕机，大量请求落到数据库，对DB造成很大的压力
解决方案：
1、给不同的可以添加不同的过期时间，如ttl后添加随机值
2、搭建高可用的redis集群
3、采用多级缓存机制
四、redis的持久化
由于redis数据是基于内存的数据库，一旦出现宕机，数据就会丢失。为了解决这个问题，数据就需要持久化。redis的数据持久化有四种方式：RDB、AOF、VM、DISKSTORE。常用的主要是RDB、AOF，下面我们详细聊下这两种方式
1、RDB是redis database 缩写，中文名为快照，RDB持久化是把当前进程中数据生成快照保存在磁盘的过程，由于是某一时刻的数据快照，所以数据要早于内存中的数据。
RDB有两种触发方式：
1、手动触发。有两个命令：save、bgsave
save命令：阻塞当前redis进程，直到RDB过程完成，性能会差些，线上不建议用这种方式
bgsave命令：redis进程会fork一个子进程，快照的过程由子进程完成，阻塞也只发生在fork子进程的过程中，且这个过程很快

2、自动触发
redis.conf中 save m n ，可以开启自动触发，表示m秒内有n次修改，自动触发bgsave生成rdb文件

如图：分别表示900s内有1个key修改，触发一次bgsave；300s内有10个key修改，触发一次bgsave；60s内有10000个key修改，触发一次bgsave
2、AOF持久化 全称 append only file(追加文件) redis是写后日志，redis先执行命令把数据写入内存，然后记录日志（这样也是为了追求高的性能）。日志中记录了redis每一条执行命令，都会把命令存入aof文件中，可以理解为一个命令的文件。根据redis的执行日志，将数据持久化到磁盘.AOF这种类型默认是关闭状态。可以修改redis.conf文件开启AOF持久化

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes
------
著作权归@pdai所有
原文链接：https://pdai.tech/md/db/nosql-redis/db-redis-x-rdb-aof.html

AOF命令记录的频率也可以通过修改配置appendfsync，配置不同的同步策略，共有三种方式分别有下面的特点

AOF和RDB均有自己的优缺点，可以结合使用

五、redis高可用

对于单节点的redis，肯定避免不了出现故障。那么如何保证redis集群的高可用性呢？有几种方案：1、主从复制 2、哨兵机制 3、分片技术
1、主从复制
主从复制，是将一个redis服务器作为主节点，数据从主节点复制到从节点。配置多个节点 可用使用读写分离，从而提高redis的并发能力

主从全量复制的过程如下图：
1、slave节点执行replicaof命令建立连接
2、请求数据同步
3、master判断是否是第一次同步
4、如果是第一次同步，返回master的数据版本信息
5、slave保存版本信息
6、master执行bgsave，生成RDB文件，并发送RDB文件给slave节点
7、slave节点清空本地的数据，加载RDB文件
8、master节点记录RDB期间的所有命令
9、master发送repl_baklog中的命令
10、slave节点执行接收到

主从增量复制如下图
1、从节点请求主节点数据时，主节点判断是不是首次同步，如果不是首次同步，旧获取从节点的offset值
2、主节点获取offset值后面的数据，发送给从节点

2、哨兵模式
哨兵模式的核心功能是主节点的自动故障转移。如果主节点发生故障时，从节点会自动上升为主节点，旧的主节点降级为从节点。如下图是哨兵模式的逻辑图

监控：哨兵会不断检查所有节点是否正常运行
自动故障转移：当主节点不能正常工作时，哨兵会开始自动开始故障转移操作，从从节点中选举中一个节点升级为主节点
通知：当发生故障转移时，哨兵会把这个转移的结果通知给redis客户端

主节点下线的判定
主动下线：当哨兵超过特定的时间内没有响应，则认为主动下线
客观下线：当超过规定数量的哨兵均认为节点下线（规定的数量最好超过哨兵数量的一半），就认为该主节点是客观下线
哨兵的选举机制
哨兵的选举机制其实很简单，就是一个Raft选举算法： 选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举
任何一个想成为leader的哨兵，要满足两个条件
1、拿到一半的票数
2、票数大雨等于哨兵配置文件中的quorum值
新主库的选出
主库既然已经下线了，如何选出新的主节点呢？
1、首先过滤掉不健康和没有回复哨兵的从节点
2、根据从节点的优先级，选出优先级高的节点
3、从优先级高的节点中选出复制偏移量最大的节点，只复制最完整的节点

3、redis 分片
redia分片引入hash槽的概念，redis集群有16384个hash槽，每个key同过CRC16检验后对16384取模决定放在哪个槽里，集群中每个节点负责一部分hash槽

六、redis单线程为什么这么快呢？

1、redis是纯内存操作，速度比较快
2、单线程，避免了多线程中的上下文切换
3、采用io多路复用模型，非阻塞io
io多路复用模型：利用单个线程来同时监听多个socket，并在某个socket可读、可写时得倒通知，避免无效的等待时间充分利用cpu的资源

参考文档：https://pdai.tech/md/db/nosql-redis/db-redis-x-cluster.html