【Java】Redis（中间件）

一、对Redis的理解

Reids是一种基于内存的数据库，对数据的读写操作都在内存中完成，因此读写速度非常快，常用于缓存、消息队列、分布式锁等场景。除此之外，Redis还支持事务、持久化、Lua脚本、多种集群方案（主从复制模式、哨兵模式、切片机群模式）、发布/订阅模式、内存淘汰机制、过期删除机制等等。

二、五大基本数据类型

1、String（字符串）

String类型的底层数据结构实现主要是SDS（简单的动态字符串）。

SDS 不仅可以保存文本数据，还可以保存二进制数据。SDS的所有API都会以处理二进制的方式来处理SDS存放在buf[]数组中的数据。所以 SDS不仅可以保存文本数据，还可以保存图片、音频、视频等这些二进制数据。
SDS 获取字符串长度的实践复杂度为O(1)。因为SDS不是采用C语言的“\0”来判断字符串是否结束，而是采用len属性的值，所以时间复杂度为O（1）；
Redis 的 SDS API 是安全的，拼接字符串不会造成缓冲区溢出。因为 SDS 在拼接之前对 SDS 的空间进行检查，不满足会进行扩容。

2、List（列表）

List类型的底层数据结构是由双向链表或压缩指针实现：

如果列表的元素个数小于 512 个（默认值，可由 list-max-ziplist-entries 配置），列表每个元素的值都小于 64 字节（默认值，可由 list-max-ziplist-value 配置），Redis 会使用压缩列表作为 List 类型的底层数据结构；
如果列表的元素不满足上面的条件，Redis 会使用双向链表作为 List 类型的底层数据结构；
但是在 Redis 3.2 版本之后，List 数据类型底层数据结构就只由 quicklist 实现了，替代了双向链表和压缩列表。

3、Hash（散列）

Hash 类型的底层数据结构是由压缩列表或哈希表实现的

如果哈希类型元素个数小于 512 个（默认值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字节（默认值，可由 hash-max-ziplist-value 配置）的话，Redis 会使用压缩列表作为 Hash 类型的底层数据结构；
如果哈希类型元素不满足上面条件，Redis 会使用哈希表作为 Hash 类型的底层数据结构。在
Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

4、Set（集合）

Set 类型的底层数据结构是由整数集或哈希表合实现的:

如果集合中的元素都是整数且元素个数小于 512（默认值，set-maxintset-entries 配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

5、sorted_set（有序集合）

Set 类型的底层数据结构是由压缩列表或跳表合实现的:

如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；
在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

三、持久化

RDB（快照形式、保存当前数据状态）

在进行保存时可能会阻塞当前redis服务器，直到当前rdb过程完成，所以如果数据量过大，可能造册长时间的阻塞，我们通常使用bgsave进行保存。RDB 触发条件：

手动触发：
- save：执行该指令后，主线程执行 rdbSave 函数，服务器进程阻塞，即不能处理任何其他请求
- bgsave(background save)：本质上这个命令和 save 差不多，区别在于这个命令会 fork 了一个子进程，去执行 rdbSave 函数，因此主线程还是可以执行新请求的。
自动触发：配置文件中写入save m n，代表当m秒内发生n次变化时，会自动执行 bgsave

AOF（以日志的方式进行持久化）

redis可以通过AOF文件，将文件中的数据修改命令全部执行一遍，以恢复数据。

AOF重写：

实现方式：创建一个新的AOF文件，替换原来的AOF文件。

AOF恢复：

AOF 触发条件

手动触发: bgrewriteaof
自动触发：配置文件中设置 appendonly yes 开启
自动触发的写入策略:
- Always：即同步写回，在每个写命令执行完成后，直接将命令落入磁盘文件（数据基本保证可靠性，但是影响 Redis 的性能）
- Everysec：即每秒写回，对于每个命令执行完成后，该命令被写入文件的内存缓存区，每过 1 秒，redis 会把该缓存区命令写到磁盘的 AOF 文件中（出了问题最多丢失一秒内数据，性能影响较小）
- No：这个 No 不是不执行 AOF，而是将操作命令全部只写到 Redis 缓存区，至于在何时将缓存数据落盘，交给操作系统决定（出了问题，数据丢失情况不可控，性能影响最小）

四、删除策略

1、基于过期时间（数据创建时固定时间）（过期的数据并没有真正的删除）

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态 XX ：具有时效性的数据

-1 ：永久有效的数据

-2 ：已经过期的数据或被删除的数据或未定义的数据

过期删除策略：

定时删除

创建定时器，当set数据设置的定时时间到达时，由定时器对该键值对执行删除任务，但是在执行期间会阻塞cpu，先进行删除，删除完成后才会释放cpu。（用cpu性能换区空间，那时间换空间）

惰性删除

当数据过期时，不做处理，当下次访问该数据时再进行删除，并返回不存在该数据。虽然会节约cpu的性能，但当过期数据一直不被访问时，则会长期占用内存。（相当于用内存空间来换取时间，cpu的性能）

定期删除（定时删除+惰性删除）

redis会主动执行定时删除策略，当不执行定期删除策略时，则执行惰性删除策略。

2、基于内存淘汰（内存满时）

LRU（最近最少使用）

传统的LRU算法是基于【链表】实现，链表中的元素会按照操作顺序从前往后进行排序，最新的操作的键会被移动到表头，当需要淘汰元素时，直接从表尾进行淘汰。

Redis并没有使用这样的方式进行实现LRU，因为会存在两个问题：

1、需要使用链表管理所有的缓存数据，会带来额外的空间开销。

2、当有数据被访问时，需要将链表中的元素移到表头，会很耗时，降低Redis缓存的性能。

Rids如何实现LRU算法？

它的实现方式是在Redis的对象结构体中添加一个额外的字段，用来保存该数据最后一次访问的时间。当Redis进行内存淘汰时，会使用随机采样的方式来进行淘汰数据，它会随机选取5个值，然后淘汰最久没有使用的那个。可以解决传承LRU存在的两个问题。但也会出现新的问题【缓存污染问题】：当软件一次读取大量数据，而这些数据只需要使用一次，那么这些数据就会在Redis缓存中存在很长的时间，造成数据污染。因此在Redis4.0后引入了 LFU 算法。

LFU（最近最不常用）

LFU 算法是根据访问次数来决定淘汰数据，他的核心思想【如果数据被访问多次，那将来的访问的频率也会更高】，所以 LFU 算法会记录每个数据的访问次数，当数据被访问一次则会增加一次访问次数，这样就解决了 LRU 中数据污染的问题。

Rids如何实现LFU算法？

Redis对象头中的24bits的lru字段被分为，高16bit存储idt，低8bit用来存储logc。

ldt：是用来记录key被访问的时间戳。
logc：是用来记录key的访问频次【不是次数】，数值越小越容易被淘汰，key初始值为5。

Redis在访问key时，对 logc 的变化：

先按照这次访问时间和上次访问时间的间隔，对 logc 进行衰减；
再按一定的概率增加 logc 的值；

五、企业级解决方案

缓存击穿

当一个热点key突然失效时，那么这些请求就会击穿缓存（Redis）自己对数据库进行查找，从而导致性能下降。

解决方案：

1、可以将key设置成永不过期的状态；

2、可以加锁排队，当一个key突然失效，会有一个线程进入数据库进行查询，并将读取的数据重新放回 Reids 缓存中，该过程在加锁的状态下只允许一个线程对数据库进行请求，当第一个线程将数据写入缓存就可以正常进行查询。

缓存雪崩

当大量key集中失效时，或者缓存服务宕机，会导致大量请求访问数据库，造成压力过大，甚至宕机。

解决方案：

1、给不同的Key的TTL添加随机值

2、利用Redis集群提高服务的可用性

3、给缓存业务添加降级限流策略

4、给业务添加多级缓存

缓存穿透

当大量请求所查询的值缓存和数据库中都不存在时，会对数据库进行查询，会导致压力过大，甚至宕机。

解决方案：

1、缓存空对象:单的解决方案就是哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis 中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到缓存了

2、布隆过滤

六、主从复制

Redis 主从复制（Master-Slave Replication）是 Redis 实现高可用、数据备份和读写分离的核心机制。其核心思想是：一个主节点（Master）负责处理写操作和数据同步，多个从节点（Slave）通过复制主节点的数据，仅处理读操作，从而分担主节点压力、提高系统吞吐量，并实现数据冗余。