Redis
一、使用场景
1.1缓存
1.1.1 缓存穿透
概念
缓存穿透是指查询一个DB中不存在的数据，mysql数据库查询不到也不会直接写入redis缓存，就会导致每次请求该不存在的数据都需要查询数据库，可能导致DB挂掉；
解决方案
方案1：缓存空数据
- 查询返回的数据为空，仍把这个空结果进行缓存，即{key:1,value:null}
- 优缺点
优点：简单；
缺点：消耗内存，可能会发生不一致的问题；
方案2：布隆过滤器（常用）
- bitmap(位图)：相当于是一个以（bit）位为单位的数组，数组中每个单元只能存储二进制数0或1；
- 布隆过滤器：用于检索一个元素是否在一个集合中；
- 布隆过滤器底层原理：主要是先初始化一个比较大数组，里面存放的二进制0或1，在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标，然后把数组中原来的0改为1，三个数组的位置就能表明一个key的存在，查找的过程相同；
- 优缺点
优点：内存占用较少，没有多余key；
缺点：实现复杂，存在误判；
1.1.2 缓存击穿
概念
缓存击穿是给某一个key设置过期时间，当key过期的时候，恰好在过期时间点对这个key有大量的并发请求，这些并发的请求可能会瞬间把DB压垮；
解决方案
方案1：互斥锁
实现原理：
- 查询缓存中的数据，发现数据失效，此时不立即访问数据库（load db）；
- 设置互斥锁，如使用redis的setnx设置互斥锁；
- 再进行load db查找数据操作，将数据缓存到redis中；
方案2：逻辑过期
实现原理：
- 在设置key时，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间；
- 当查询时，从redis取出数据后判断时间是否过期；
- 如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新。
1.1.3 缓存雪崩
概念
缓存雪崩是指在同一时段大量的缓存key同时失效或redis服务宕机，导致大量请求到达数据库查询数据，给数据库带来了极大的压力；
解决方案
方案1：给不同的Key的TTL添加随机值（主要）
在原有的失效时间基础上添加一个随机值（1~5分钟随机），这样每一个缓存的过期时间的重复率会降低，进而很难引发集体失效的事件；
方案2：利用Redis集群提高服务的可用性
方案3：给缓存业务添加降级限流策略
方案4：给业务添加多级缓存
1.1.4 双写一致
redis做为缓存，mysql的数据与redis进行同步，采用双写一致性。
双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致。
- 读操作：缓存命中，直接返回，缓存未命中查询数据库，写入缓存，设定超时时间；
- 写操作：延迟双删；
实现双写一致性的方案
方案1：采用redisson实现的读写锁：
- 读：添加共享锁，可保证读读不互斥，读写互斥；
- 写：添加排他锁，可保证读写、读读都互斥；
注：读方法和写方法需要使用同一把锁。
排他锁实现原理：
排他锁底层使用也是setnx，保证同时只能有一个线程操作锁的方法；
方案2：延迟双删
- 写操作：先把缓存中的数据删除，然后更新数据库，最后再延时杀出缓存中的数据（延时的时长不太确定，易出现脏数据）
1.1.5 持久化
方式1：RDB
概念
RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照，简单来说就是把内存中的所有数据都记录到磁盘中，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
# 900秒内，如果至少有1个key被修改，则执行bgsave
save 900 1
save 300 10
save 60 10000
执行原理
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。
fork采用的时copy-on-write技术：
- 当主进程执行读操作时，访问共享内存；
- 当主进程执行写操作时，则会拷贝一份数据，执行写操作；
方式2：AOF
概念
AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可看做是命令日志文件。
AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF的命令记录的频率也可以通过redis.conf文件来配置：
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
RDB和AOF比较
- RDB是二进制文件，在保存时体积较小，恢复的较快，但可能会丢失数据；
- AOF中记录的是命令，AOF文件会比RDB文件大的多，恢复的较慢，丢失数据风险小。AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
1.1.6 数据过期
Redis对数据设置的有效时间，数据过期后，就需要将数据从内存中删除，可按照不同的规则进行删除，称之为数据的删除策略（数据过期策略）；
惰性删除
概念
惰性删除：设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key（需要时检查数据是否过期，如果过期，则进行删除）；
优缺点
- 优点 ：对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查；
- 缺点 ：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放；
定期删除
概念
定期删除：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。
定期删除两种模式
- SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调整这个次数；
- FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms；
优缺点
- 优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
- 缺点：难以确定删除操作执行的时长和频率。
Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用
1.1.7 淘汰策略
概念
数据的淘汰策略：当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。
淘汰策略（8种）
noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略
volatile-ttl： 对设置了TTL(有效时间)的key，比较key的剩余TTL值，TTL越小越先被淘汰
allkeys-random：对全体key ，随机进行淘汰。
volatile-random：对设置了TTL的key ，随机进行淘汰。
allkeys-lru： 对全体key，基于LRU算法进行淘汰
volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
allkeys-lfu： 对全体key，基于LFU算法进行淘汰
volatile-lfu： 对设置了TTL的key，基于LFU算法进行淘汰
LRU（Least Recently Used）最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。例如：key1是在3s之前访问的, key2是在9s之前访问的，删除的就是key2
LFU（Least Frequently Used）最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。例如：key1最近5s访问了4次, key2最近5s访问了9次， 删除的就是key1
淘汰策略使用建议
- 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。
- 如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。
- 如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
- 如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。
1.2 分布式锁
Redis实现分布式锁主要利用Redis的setnx命令，setnx是SET if not exists(如果不存在，则SET)的简写；
1.2.1 setnx
# 添加锁，NX是互斥、EX是设置超时时间
SET lock value NX EX 10
# 释放锁，删除即可
DEL key
Redis实现分布式锁如何合理的控制锁的有效时长？
- 根据业务执行时间预估
- 给锁续期
1.2.2 redisson
在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成时，在redisson中引入了一个看门狗机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加锁的持有时间，当业务执行完成后需要使用释放锁即可；
还有就是在高并发下，一个业务有可能会执行很快，先客户1持有锁时，客户2来了就不会马上拒绝，它会自选不断尝试获取锁，如果客户1释放之后，客户2就可以马上持有锁，性能也得到了提升。
1.3 计数器
1.4 保存token
1.5 消息队列
1.6 延迟队列
二、其他
2.1 集群
2.1.1 主从复制
单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离，一般都是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中；
主从数据同步原理
- Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
- offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
主从全量同步
全量同步是指从节点第一次与主节点建立连接时使用全量同步，流程如下：
- 从节点请求主节点同步数据，其实主节点会携带子集的replication id和offset偏移量；
- 主节点判断是否是第一次请求，主要判断的依据就是，主节点与从节点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点就会把自己的replication id 和offset发送给从节点，让从节点与主节点的信息保持一致；
- 在同时主节点会执行bgsave,生成rdb文件后，发送给从节点去执行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这样就保持一致；
- 如果在rdb生成执行期间，依然有请求到了主节点，而主节点会以命令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送给从节点，这样就能保证主节点与从节点完全一致了，后期再同步数据时，都是依赖于这个日志文件；
主从增量同步（slave重启或后期数据变化）
增量同步指的是当从节点服务重启之后，数据就不一致了，所以这个时候，从节点会请求主节点同步数据，主节点还是判断不是第一次请求，不是第一次就获取从节点的offset值，然后主节点从命令日志中获取offset值之后的数据，发送给从节点济宁数据同步。
2.1.2 哨兵模式
Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复，哨兵结构和作用：
- 监控：Sentinel会不断检查您的master和slave是否按预期工作；
- 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master，当故障实例恢复后也以新的maser为主；
- 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。
服务状态监控
Sentinel基于心跳机制检测服务状态，每隔1秒向集群的每个实例发送ping命令； - 主观下线：如果某Sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线；
- 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线，quorum值最好超过Sentinel实例数量的一半。
哨兵选主规则： - 首先判断主与从节点断开时间长短，如超过指定值就排该从节点；
- 然后判断从节点的slave-priority值，越小优先级越高；
- 如果slave-prority一样，则判断slave节点的offset值，越大优先级越高；
- 最后是判断slave节点的运行id大小，越小优先级越高；
2.1.3 分片集群
主从和哨兵可解决高可用，高并发读的问题，但依然有两个问题没有解决：
- 海量数据存储问题；
- 高并发写的问题；
使用分片集群可以解决上述问题，分片集群特征：
- 集群中有多个master，每个master保存不同数据；
- 每个master都可以有多个slave节点；
- master之间通过ping检测批次健康状态；
- master之间通过ping检测彼此健康状态；
- 客户端请求可访问集群任意节点，最终都会被转发到正确节点；
分片集群结构—数据读写
Redis分片集群引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定防止哪个槽，集群的每个节点负责一部分hash槽；
2.2 事务
2.3 Redis为什么那么快
- Redis是纯内存操作，执行速度非常快；
- 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题；
- 使用I/O多路复用模型，非阻塞IO；
I/O多路复用模型：
Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟，而不是执行速度，I/O多路复用模型主要就是实现了高效的网络请求：
用户空间和内核空间
Linux系统中一个进程使用的内存情况划分两个部分：内核空间、用户空间
用户空间
只能执行受限的命令（Ring3），而且不能直接调用系统资源必须通过内核提供的接口来访问；
内核空间
可以执行特权命令（Ring0）,调用一切系统资源；
Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区；
- 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备（用户缓冲–>内核缓冲区）；
- 读数据时，要从设备读取数到内核缓冲区，然后拷贝到用户缓冲区（内核缓存区–>用户缓存区）；
常用的IO模型：
阻塞IO
顾名思义，阻塞IO就是两个阶段都必须阻塞等待：
阶段一：
用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态
阶段二：
数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据
非阻塞IO
顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。
阶段一：
1.用户进程尝试读取数据（比如网卡数据）
2.此时数据尚未到达，内核需要等待数据
3.返回异常给用户进程
4.用户进程拿到error后，再次尝试读取
5.循环往复，直到数据就绪
阶段二：
1.将内核数据拷贝到用户缓冲区
2.拷贝过程中，用户进程依然阻塞等待
3.拷贝完成，用户进程解除阻塞，处理数据
4.可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是5.非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。
IO多路复用
IO多路复用：是利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。
阶段一：
1.用户进程调用select，指定要监听的Socket集合
2.内核监听对应的多个socket
3.任意一个或多个socket数据就绪则返回readable
4.此过程中用户进程阻塞
阶段二：
1.用户进程找到就绪的socket
2.依次调用recvfrom读取数据
3.内核将数据拷贝到用户空间
4.用户进程处理数据
Redis网络模型
Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装， 提供了统一的高性能事件库
