1. 基本数据类型

  • String
  • List
  • Set
  • ZSet
  • Hash

2. 持久化

2.1 什么是持久化

持久化就是把内存的数据写到磁盘中去，防止服务宕机导致内存数据丢失。

手动save命令：通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。save 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server 进程阻塞期间，Redis不能处理任何读写请求，无法对外提供服务。

手动bgsave命令：通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命 令的是，正如该命令的名称一样，background save，后台运行 save。bgsave 命令会使服务器进程 redis-server 会fork一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程中，不会阻塞 redis-server 进程对客户端读写请求的处理。

2.2 持久化的方式

Redis提供了两种持久化方式:RDB（默认） 和AOF , 若RDB和AOF都配置了，则优先使用AOF还原数据

3.RDB

  1. 在指定的时间间隔内将内存中的数据集快照写入磁盘，即Snapshot内存快照，他恢复是再将硬盘快照文件直接读回内存里。
  2. redis的数据都在内存中，保存备份时它执行的是全量快照，即把内存所有数据存入磁盘。
  3. RDB保存的文件是dump.rdb
  4. 条件： 多少秒内有多少个key发生变化
    save 3600 1 在3600秒及其之后，且至少有1个key发生变化，则dump内存快照
    save 300 100
    save 60 10000

详解：
1. 查询最近的一次更新时间命令：lastsave 2. 例如最新的一次更新时间是2023年8月25日 11:00:00 3. save 3600 1 表示 12:00:00及其之后 只要有一个key发生变化则立即进行内存快照的保存 4. 同理： save 300 100 表示2023年8月25日 11:05:00及其之后 只要有100个key发生变化 则立即进行内存快照的保存 如果2023年8月25日 11:00:00 - 2023年8月25日 11:05:00 期间进行了99个key的变化 不保存 会一直等到最后一个key的变化立即执行保存

3.1 RDB持久化过程


3.2 RDB优势、劣势：

优势： ①适合大规模的数据恢复
②按照业务定时备份
③对数据完整性和一致性要求不高
④RDB文件在内存中的加载速度比AOF快。

劣势：
①在一定间隔时间做一次备份，如果redis意外宕机，就丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失；
②内存数据的全量同步，如果数据量太大会导致I/O严重影响服务性能
③RDB依赖于主进程的fork，在更大数据集上，可能导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致膨胀两倍。需要考虑。

4 AOF

4.1AOF介绍

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件，但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。
默认情况下，redis没有开启AOF，开启配置：appendonly yes。
AOF保存的时appendonly.aof文件

4.2 Aof缓冲区写会策略

Always：同步写回，每个写命令执行完立刻同步的将日志写回磁盘。可靠性高，数据基本不丢失
everysec：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘。性能较好  （默认）
no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。性能好

4.3AOF优势、劣势

优势：
更好的保护数据不丢失、性能高、可做紧急回复。
劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。
aof运行效率要慢于rdb，每秒同步策略较好，不同步效率和rdb相同。

4.4 AOF重写机制

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

①触发机制之手动触发：客户端向服务器发送bgrewriteaof命令。

②触发机制之自动触发：满足配置文件中的选项后，Redis会记录上次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

4.5AOF持久化过程

5. Aof重写机制

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

  #默认配置
  #同时满足，且的关系才会触发
  # 根据上次重写后的aof大小，判断当前aof大小是否增长了100%
  auto-aof-rewrite-percentage 100
  # 重写是满足的文件大小
  auto-aof-rewrite-min-size 64mb

5.1 触发方法

  • 满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，当AOF文件是上次rewrite后大小的一倍且文件大于64M时
  • 客户端向服务器发送bgwriteaof命令

5.2 重写原理

Redis AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的价值对，然后用一条命令去代替之前这个键值对的多个命令，生成一个新的文件后去替换原来的AOF文件

6. key过期策略

1.立即删除：
    在设置键的过期时间时，会创建一个回调事件，当过期时间达到时， 自动执行回调事件去删除键。但是立即删除对 cpu 是最不友好的。
2.惰性删除：
    惰性删除是指某个键值过期后，此键值不会马上被删除，而是加入到删除字典(dict和expires)当中，等到下次被使用的时候，才会被检查到过期，此时才能得到删除。所以惰性删除的缺点就是会浪费内存。
3.定期删除：
    每隔一段时间，对删除字典中进行检查，删除里面的过期键。 默认情况下是每秒进行10次过期扫描即100ms/次，参数 hz
    可以看到，第二种为被动删除，第一种和第三种为主动删除，且第一种实时性更高。每隔一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，来减少删除操作对 cpu 的影响。另一方面定时删除也有效的减少了因惰性删除带来的内存浪费。

Redis中同时使用了惰性过期和定期过期两种过期策略。

7. 内存淘汰策略

  noeviction：只返回错误，不会删除任何key。该策略是Redis的默认淘汰策略，一般不会选用。
  volatile-ttl：将设置了过期时间的key中即将过期（剩余存活时间最短）的key删除掉。
  volatile-random：在设置了过期时间的key中，随机删除某个key。
  allkeys-random：从所有key中随机删除某个key。
  volatile-lru：基于LRU算法，从设置了过期时间的key中，删除掉最近最少使用的key。
  allkeys-lru：基于LRU算法，从所有key中，删除掉最近最少使用的key。该策略是最常使用的策略。
  volatile-lfu：基于LFU算法，从设置了过期时间的key中，删除掉最不经常使用（使用次数最少）的key。
  allkeys-lfu：基于LFU算法，从所有key中，删除掉最不经常使用（使用次数最少）的key。

8. redis配置文件详解

https://blog.csdn.net/qq_44749491/article/details/128091887

9. RedissonClient常用的API

10. Redis单线程为什么那么快

https://blog.csdn.net/xlgen157387/article/details/79470556
1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap
2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
4、多路 I/O 复用模型
5、因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了
6、IO多路复用模型
    IO多路指的是 ： 网络请求是多线程的
    复用：对于Redis内部处理网络请求 是复用的的单个线程
    Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现(select、poll、epoll)，并且将这些实现进行封装，提供了统一的高性能事件库。

11. 关于redis多线程的考量

参考链接：https://blog.csdn.net/weixin_38915773/article/details/131177186
Redis6.0 引入多线程来提高网络 IO 读写性能。 当前版本已经是7.2.0了 https://redis.io/download/
实际处理数据 还是单线程 多线程只是处理网络请求

这里要注意的是Redis 的多线程只是在网络数据的读写这类耗时操作上使用了， 执行命令仍然是单线程顺序执行。Redis6中默认是禁用多线程的，可以通过修改redis的配置文件中io-threads-do-reads=true来开启。除此之外还需要设置现场的数量才能正真开启多线程，配置参数为io-threads 4表示开启四个线程。

线程设置建议：关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。