Redis
1.说一下对Redis的理解
redis是一个分布式的KV数据库，不同于mysql等常规数据库将数据存储在硬盘，它是将数据存储在内存之中，所以查询速度很快，经常用来做缓存，又因为redis核心操作是单线程的可以保证命令的原子性执行，所以可以用作分布式锁来使用。
2.redis数据类型以及常见场景
-
String：字符串类型
使用场景：分布式锁，权限
-
List：有序的字符串列表，支持在头部或尾部插入和删除元素
使用场景：缓存一些需要顺序存储的集合
-
Set：无序且去重的集合
使用场景：出库入库操作，需要提升速度，存放箱号，袋号，
-
Hash：键值对的集合，适合存储对象，可以单独修改对象属性
-
Zset：与 Set 类似，但每个元素都关联一个分数（score），元素按分数排序
3.redis持久化策略
Redis 是一个基于内存的键值存储系统，为了确保数据在重启或崩溃后不丢失，Redis 提供了两种主要的持久化策略：RDB（Redis DataBase） 和 AOF（Append-Only File） 。这两种策略各有优缺点，可以根据实际需求选择使用其中一种或同时使用两种。
1. RDB（Redis DataBase）
RDB 是 Redis 的默认持久化方式，它通过生成数据快照（Snapshot）来保存某一时刻的数据库状态。
工作原理
- Redis 会定期将内存中的数据以二进制格式保存到磁盘上的 RDB 文件中。
- 可以通过配置文件设置快照的触发条件，例如： save 900 1 # 在 900 秒内，如果至少有 1 个键被修改，则触发快照 save 300 10 # 在 300 秒内，如果至少有 10 个键被修改，则触发快照 save 60 10000 # 在 60 秒内，如果至少有 10000 个键被修改，则触发快照
- 也可以手动执行
SAVE或BGSAVE命令生成快照：SAVE：阻塞主线程，直到快照完成。BGSAVE：在后台异步生成快照，不阻塞主线程。
RDB的几个优点
- 与AOF方式相比，通过rdb文件恢复数据比较快。
- rdb文件非常紧凑，适合于数据备份。
- 通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。
RDB的几个缺点
- 如果服务器宕机的话，采用
RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。 - 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
- 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
2. AOF（Append-only file）
工作原理
与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。
AOF三种写入策略
在上面的配置文件中，我们可以通过appendfsync选项指定写入策略,有三个选项
appendfsync always
# appendfsync everysec (defaul)
# appendfsync no
1. always
客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
2. everysec
appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。
3. no
Redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。
AOF文件重写
AOF将客户端的每一个写操作都追加到aof文件末尾，比如对一个key多次执行incr命令，这时候，aof保存每一次命令到aof文件中，aof文件会变得非常大。
代码解读
复制代码
incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
代码解读
复制代码
set num 100000
aof文件是一个二进制文件，并不是像上面的例子一样，直接保存每个命令，而使用Redis自己的格式，上面只是方便演示。
两种重写方式
通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性以，因此默认值为no，不推荐使用。
# 默认不重写aof文件
no-appendfsync-on-rewrite no
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
# 让服务器异步重写追加aof文件命令
> bgrewriteaof
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
重写aof文件的好处
- 压缩aof文件，减少磁盘占用量。
- 将aof的命令压缩为最小命令集，加快了数据恢复的速度。
AOF的优点
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
AOF的缺点
- AOF方式生成的日志文件太大，即使通过AOF重写，文件体积仍然很大。
- 恢复数据的速度比RDB慢。
如何选择持久化策略
根据实际情况来判断，如果仅仅是使用redis做缓存那可以不使用持久化策略，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
