Redis专题

Redis基础

五种数据结构：字符串string，哈希hash，列表list，集合set，有序结合zset

Redis的单线程和高性能

Redis是单线程吗？

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外 提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其
实是由额外的线程执行的。

Redis 单线程为什么还能这么快？

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性 能损耗问题。

Redis 单线程如何处理那么多的并发客户端连接

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到 文件事件分派器，事件分派器将事件分发给事件处理器。

Redis持久化方式

RDB

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
在配置文件中配置多少秒内有多少个键值发生改变，自动保存一次；也可以手动执行命令save或bgsave生成dump.rdb文件

AOF

RDB快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失 最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方 式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof（resp协议格式数据）中(先写入os cache，每隔一段时间 fsync到磁盘)

可以配置 Redis 多久才将数据 fsync 到磁盘一次。 有三个选项：

1. appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
2. appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
3. appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
   推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

AOF重写：AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

如下两个配置可以控制AOF自动重写频率 :

1. auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就 很快，重写的意义不大
2. auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF

Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重 放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很 长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将 重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一 起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改 名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。 于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构如下：

Redis主从架构

https://blog.csdn.net/weixin_41605937/article/details/114369313

redis高并发与分布式系统的高并发之间的关系：大量使用redis技术的分布式系统，它的高并发能力与redis的高并发密切相关，因此要向提升分布式系统的高并发能力，就要提升redis在高并发场景下的性能。如果我们生产环境中使用的redis是单机的，那么redis的整体性能一定是有瓶颈的。单机的redis要想支撑超过10万+的QPS，是不太可能的，正常情况下单机的QPS在几万级别。。因此，我们说redis支撑高并发的瓶颈在于单机，那么如果redis要支撑10万+的并发，应该怎么做到呢？要想支撑10万+的QPS，我们可以通过基于一主多从的读写分离架构来实现，一台机器作为master，其他机器作为slave，写请求只通过master，slave用来接收读请求。项目中使用到redis的场景，一般是读多写少的，因此我们可以用多个slave来缓解读请求压力，达到支撑10万+读QPS的目的。需要说明的是，redis主从架构实现了读写分离，缓解了单机的读请求压力，提升了整个redis的读QPS。如果我们需要实现更高的读QPS，就可以加一些slave节点，所以我们说redis主从架构其实是可支持水平扩展的读高并发架构。

配置步骤

Redis主从工作原理

• 主从复制(全量复制)

1. 从节点跟主节点简历socket长连接，发送fsync命令请求同步数据
2. 主节点接收到命令后通过bgsave生成rdb快照，并将之后的客户端请求命令缓存在内存
3. 主节点将rdb快照发送给从节点，从节点将rdb数据加载到内存
4. 主节点将缓存命令发送给从节点，从节点执行指令
5. 主节点通过长连接保持与从节点数据一致

• 主从复制(部分复制，断点续传)
  当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支 持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分 数据复制(断点续传)。 master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的 slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master 继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标 offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。
• 主从复制风暴
  如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如下架构，让部分从节点与从节点(与主节点同步)同步数据
  

Redis哨兵高可用架构

哨兵主要是为了解决主从复制架构中出现宕机的情况，在主节点出现宕机时，哨兵会自动将主节点下的某个从节点升级为新的主节点
sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

Redis3.0+ 集群功能

一个集群总共16383hash槽，需自行分配到各master上，如果新增master，需要从其他master分配hash槽，如果删除master，需先将hash槽转移，否则会数据丢失。

缓存设计与性能优化

缓存穿透：
缓存穿透是指查询一个根本不存在的数据， 缓存层和存储层都不会命中， 通常出于容错的考虑， 如果从存储 层查不到数据则不写入缓存层。 缓存穿透将导致不存在的数据每次请求都要到存储层去查询， 失去了缓存保护后端存储的意义。 造成缓存穿透的基本原因有两个： 第一， 自身业务代码或者数据出现问题。 第二， 一些恶意攻击、 爬虫等造成大量空命中。
缓存穿透问题解决方案：

1. 缓存空对象
2. 布隆过滤器

缓存失效(击穿)：
由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大 甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同 时间。

缓存雪崩：
缓存雪崩指的是缓存层支撑不住或宕掉后， 流量会像奔逃的野牛一样， 打向后端存储层。 由于缓存层承载着大量请求， 有效地保护了存储层， 但是如果缓存层由于某些原因不能提供服务(比如超大并 发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下 降)， 于是大量请求都会打到存储层， 存储层的调用量会暴增， 造成存储层也会级联宕机的情况。