网站建设公司排名前十广告设计公司采购合同

缓存

缓存穿透

当查询一个不存在的数据，mysql查询不到数据，无法写入缓存，导致每次都请求数据库

解决方法

• 缓存空数据，当查询结果未空，将结果进行缓存。 简单但是会消耗内存，而且会出现不一致情况。
• 布隆过滤器，检索一个元素是否在集合中，缓存预热时，也要预热过滤器。 内存占用少，不会产生多余key，但是实现复杂且存在误判情况。

缓存击穿

给key设置了过期时间，当该key过期时，出现大量针对该key的请求，可能会瞬间将数据库压垮。

解决方法

• 添加互斥锁
  强一致性，但是性能差
• 逻辑过期
  热点key不设置过期时间，设置一逻辑过期时间，对于逻辑过期的key，启用新线程更改数据，原线程仍然返回过期数据。
  

缓存雪崩

同一时间大量key过期，或redis服务宕机，导致大量请求同时达到数据库。

解决方法

• 给不同key的TTL添加随机值
• Redis集群 （哨兵模式、集群模式）
• 缓存业务添加降级限流机制
• 业务多级缓存

双写一致性

设置前提，介绍背景业务

实现方法

高一致性

1. 延迟双删
   

修改数据库的同时也要更新缓存的数据，缓存于数据库保持一致。

读：命中直接返回，未命中则查询DB，将结果写入缓存，设定超时时间

写：延迟双删（依旧存在脏数据风险）

Quetion

-先删缓存还是先删数据库
无论先删除哪个都存在不一致性问题

• 为何要删除两次
  防止在修改数据库期间，其他线程将旧的结果写入缓存
• 为何延时删除
  保证redis集群的主从一致性。

2. 分布式锁
   保证缓存和数据库的绝对一致性，但是性能低。适用于读多写少的情况。
   

最终一致性

异步通知，保证数据的最终一致性

二进制日志记录（binlog）中记录所有 DDl（数据定义语言）和 DML（数据操纵语言），但不包括查询语言。

Redis持久化

RDB

RDB (Redis Database Backup file, Redis数据备份文件)，也叫redis数据快照，将数据记录到磁盘中，每次redis实列故障重启后，都会从磁盘中读取快照，回复数据。

备份方式

• 主动备份

save #主线程备份
bgsave #启用子线程备份

• 内部触发
  通过redis.conf文件中修改配置项实现

save 900 1 #900s内有一次修改
save 300 10
save 60 10000

RDB执行原理

bgsave开始时，通过fork主进程得到子进程。子进程共享fork内部数据，完成fork后读取内存写入RDB文件。

fork操作采用copy-on-write技术

• 当主进执行读操作时，访问共享内存
• 当主进程执行写操作时，会拷贝一份数据，再进行写操作
  

AOF

AOF(Append Only File, 追加文件)，Redis处理的每一个写命令都会被记录再AOF文件中。
默认关闭，可以再redis.conf中配置选项。

AOF记录频率

模式	频率	优点	缺点
always	同步	可靠性高，几乎不会出现数据丢失现象	对性能影响大
everysec	每秒	适中	最多丢失1s数据
no	由操作系统控制	最好	可靠性差，可能丢失大量数据

由于是记录文件，会比RDB大很多。AOF会记录对于同一个key的多次写操作，但是只有最后一个才有意义。可以使用bgrewriteaof命令来使AOF执行重写操作，确保最少的命令达到相同效果。

也可以通过再conf文件中进行配置，使系统内部自动触发。

# AOF文件比上次增长百分之多少重写
auto-aof-rewrite-percentage 100
# AOF文件大小超过多少重写
auto-aof-rewrite-min-size 64mb

RDB与AOF之间比较

	RDB	AOF
持久化	定期对内存进行快照	记录每次执行的写操作
完整性	不完整，两次备份之间会存在丢失	相对完整，取决于刷新策略
文件大小	小	大
宕机恢复	快	慢
数据恢复优先级	低	高
系统资源占用	高，大量CPU和内存消耗	低，主要为磁盘IO资源，但是重写时会占用大量内存资源
使用场景	可容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求更高

数据过期策略

Redis中设置有效期后的key，在数据过期后，需要将数据从内存中删除。Redis中有惰性删除和定期删除两种不同的数据过期策略，一般二者配合使用。

惰性删除

需要使用某key时，检查其是否过期，如过期则删除该key，反之直接返回该key对应值。

• 优点：CPU友好，只有需要使用该key时才会进行过期检查
• 缺点： 对内存不友好，过期的key如果不被访问，会一直存在于内存中，永远不会释放。

定期删除

每隔一段时间，从一定数量的数据库中随机选择一部分key进行检查，并删除过期key。
定期删除有两种模式：

    SLOW: 定时任务，执行频率默认10hz，每次不超过25msFAST：执行频率不固定，但每次间隔不会低于2ms

优缺点

• 优点： 限制删除操作的时长和频率，减少对CPU影响。定期删除能有效释放过期key占用的内存。
• 缺点： 难以确定删除操作花费的时长和频率。

Redis数据淘汰策略

Redis内存不够时，接收到新的key，按照一定规则删除其中的数据。

8种淘汰策略

• noeviction： 不淘汰任何key，但内存写满时不写入（默认模式）。
• volatile-ttl： 对设置ttl的key，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：最近最少使用；LFU：最少频率使用

使用场所

• allkeys-lru： 有明显冷热数据区分
• allkeys-random： 无明显冷热数据区分
• volatile-lru： 有置顶需求，置顶数据不设过期时间
• allkeys-lfu / volatile-lfu： 有短时高频访问数据

分布式锁

用于集群下定时、抢单功能

setnx

redis中自带命令，用于创建不存在的key, 如果key存在，返回null

获取锁

set lock value nx ex 10

释放锁

del key

如何控制有效时长

• 根据业务执行时间预估
• 给锁续期

如何实现

使用redisson实现分布式锁，底层为setnx和lua脚本。通过watchdog和给锁续期的方式来控制时长。

Redisson

实现分布式锁的流程

可重入性质

判断是否是同一个线程，同一个线程可重入。利用hash结构记录线程id和重入次数。

主从一致性

不能解决主从一致性问题，当主节点宕机后，watchdog（看门狗）会选择一个从节点提升为主节点。

红锁

在不止一个实例上加锁，一般加锁实例数量大于等于（n/2+1）。可以一定程度上实现主从一致性，但是实现复杂，并发性差，运维复杂。

如果必须要实现主从一致性，使用基于CP思想的缓存工具，如zookeeper。

Redis集群

主从复制

单节点Redis并发能力有上限，要进一步提高Redis并发能力，需要搭建组从集群，实现读写分离。一般是一主多从，主节点负责写数据，从节点负责读数据。

原理

全量同步

• replid 数据集的标记，id一致说明数据集一致
• offset：偏移量。slave的offset小于master的，说明slave的数据落后于master，需要同步

增量同步

slave重启或者后期数据变化

哨兵机制（sentinel）

Redis提供哨兵机制来实现主从集群的自动故障恢复。

特点

• 监控： sentinel不断检查master和slave是否按预期工作
• 自动恢复： 如果master节点故障，哨兵集群会将一个新的slave节点提升为master节点，并在之后一直以该master节点为主
• 通知redis客户端： 哨兵充当客户端的服务通知来源，当集群发生故障转移时，会将最新信息推送道redis客户端。

作用机制

• 服务状态监控
  哨兵基于心跳机制监测服务状态，每个1s向集群中的每个实例发送ping命令

• 判断redis节点下线
  主观下线： 某个sentinel节点发现某一个实例未在规定时间内进行响应，认为该实例主观下线。
  客观下线： 超过指定数量（quorum，一般超过哨兵节点数量的一半）的哨兵节点都认为某一实例主观下线，则认为该实例已经客观下线。

• 哨兵挑选新主节点规则

1. 判断主节点与从节点断开时间长短，排除超过阈值的从节点
2. 判断从节点的slave-priority值，值越小优先级越高
3. 如果slave-priority值相同，则判断从节点的offset值，offset值越大的优先级越高。
4. 在优先级相同的节点中随机选择一个节点。

如何解决redis集群脑裂

集群脑裂是由于主节点、从节点和sentinel集群不在同一分区，使得sentinel无法通过心跳感知到主节点，通过选举提升了一个新的主节点。同时，由于旧主节点没有真实下线，客户端还在向旧主节点写入数据，新主节点无法同步数据。当网络回复后，sentinel讲旧的主节点降为从节点，再从新主节点中同步数据。这会导致客户端向旧主节点中写入的数据丢失。

解决方法： 可以通过修改redis配置文件，设置最少从节点数量和主从数据同步要求（数据复制和同步的延迟阈值），达不到要求就拒绝请求，由此避免大量数据的损失。

分片集群

用于解决海量数据存储和高并发写的问题

特点

1. 集群中有多个master，每个master节点保存不同数据
2. 每个master节点有多个slave节点
3. master节点之间通过ping值监测彼此的健康状态
4. 客户端可以向任意节点发送请求，最终都会被转发到正确节点

redis分片集群如何读写

1. 引入哈希槽的概念，redis集群有16384个哈希槽
2. 将16384个插槽分配到不同实例
3. 读写数据时，利用key的有效部分计算hash，对16384取余，余数作为插槽，最后寻找插槽所属实例。

其它

Redis是单线程的，但是为什么速度快？

• 最主要原因是Redis是纯内存操作，执行速度快
• 采用单线程，避免了不必要的上下文切换可竞争条件
• 使用多路I/O复用模型，非阻塞IO。例如，bgsave和bgwriteaof都是在后台执行，不影响主线程的正常使用，不会产生阻塞

I/O多路复用模型

I/O多路复用模型是指利用单个线程来同时监听多个socket，并在某个Socket可读、可写时得到通知，从而避免了无效的等待，充分利用CPU资源。目前的I/O多路复用模型都是通过epoll实现，它会在通知用户Socket就绪的同时，将已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。

其中Redis的网络模型就是使用I/O多路复用结合时间的处理器来应对多个Socket的请求，比如，提供了连接应答处理器、命令回复处理器，命令请求处理器；在Reids6.0之后，为了更好提升性能，在命令回复处理器中使用了多线程来处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，也依然是单线程。