redis

概念

概念：Redis (Remote Dictionary Server远程字典服务) 。使用ANSIC语言编写遵守BSD协议.是一个高性能的Key-Value数据库提供了丰富的数据结构(例如String,Hash,List,Set,SortedSet等). 数据是存在内存中的, 同时Redis支持事务,持久化,LUA脚本,发布/订阅,缓存淘汰,流技术等多种功能特性提供了主从模式,Redis Sentinel和Redis Cluster集群架构方案

特征：

1. 数据间没有必然的关联关系
2. 内部采用单线程机制进行工作
3. 高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
4. 多数据类型支持(10种)
   1. 字符串类型 string
   2. 列表类型 list
   3. 散列类型 hash
   4. 集合类型 set
   5. 有序集合类型 zset(sorted_set)
   6. 位图 bitmap
   7. 基数统计 HyperLogLog
   8. 地理空间 GEO
   9. 流 Stream
   10. 位域 bitfield
5. 支持持久化，可以进行数据灾难恢复

应用场景

为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等
即时信息查询，如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等
时效性信息控制，如验证码控制、投票控制等
分布式数据共享，如分布式集群架构中的 session 分离
消息队列

入门操作

string

基本操作

SET name value //存
GET name		//取

添加/修改

set key value

获取

get key

删除

del key

判断性添加

setnx key value

添加修改多个数据

mset key1 value1 key2 value2 …

添加获取多个数据

mget key1 key2…

获取数据字符个数

strlen key

追加信息到原始信息后部（如果原始信息存在就追加，否则新建

append key value

扩展操作

设置数值数据增加指定范围的值

incr操作的数据不存在会从1开始，如果

incr key
incrby key increment
incrbyfloat key increment

设置数值数据减少指定范围的值

decr key
decrby key increment

设置数据具有指定的生命周期

setex key seconds value
psetex key milliseconds value

扩展操作注意事项

1. 数据操作不成功的反馈与数据正常操作之间的差异表示运行结果是否成功
   (integer) 0 → false 失败
   (integer) 1 → true 成功
   表示运行结果值
   (integer) 3 → 3 3个
   (integer) 1 → 1 1个

2. 数据未获取到时，对应的数据为（nil），等同于null

3. 数据最大存储量：512MB

4. string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算

5. 按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错
   9223372036854775807（java中Long型数据最大值，Long.MAX_VALUE）

6. redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响

key的命名规范

格式: 表名:主键名:主键值:字段名

比如 user:uid:1:name

在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可

eg:	user: id:3506728370:fans	→	12210947
eg:	user: id:3506728370:blogs	→	6164
eg:	user: id:3506728370:focuses	→	83

hash

基本操作

添加/修改

hset key field value

获取

hget key field
hgetall key

删除

hdel key field1 [field2]

设置filed，如果field已经存在则不做任何操作

hsetnx key field value

添加修改多个数据

hmset key field1 value1 field2 value2 …

获取多个数据

hmget key field1 field2 …

获取哈希表中字段数量

hlen key

获取哈希表中是否存在指定的字段

hexists key field

扩展操作

获取哈希表中所有的字段名或字段值

hkeys key
hvals key

设置指定字段的数值数据增加指定范围的值

hincrby key field increment
hincrbyfloat key field increment

注意事项

1. hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
2. 每个 hash 可以存储 232 - 1 个键值对
3. hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
4. hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈

应用场景

需求描述

双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000 张

解决方案

以商家id作为key
将参与抢购的商品id作为field
将参与抢购的商品数量作为对应的value
抢购时使用降值的方式控制产品数量

list

数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
list类型：保存多个数据，底层使用双向链表存储结构实现

基本操作

添加修改

lpush key value1 [value2] ……
rpush key value1 [value2] ……

获取

lrange key start stop //start从0开始，如果全部获取start=0,stop=-1
lindex key index
llen key

获取后并删除

lpop key
rpop key

扩展操作

移出指定数据

lrem key count value

规定时间内获取并移出数据

blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout //把source中的弹到destination

注意事项

1. list中保存的数据都是string类型的，数据总容量是有限的，最多232 - 1 个元素(4294967295)。
2. list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
3. 获取全部数据操作结束索引设置为-1
4. list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载

应用场景

需求描述

企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

问题解决

依赖list的数据具有顺序的特征对信息进行管理

使用队列模型解决多路信息汇总合并的问题

使用栈模型解决最新消息的问题

set

新的存储需求：存储大量的数据，在查询方面提供更高的效率

需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的

基本操作

添加

sadd key member1 [member2]

获取

smembers key

删除

srem key member1 [member2]

获取集合数据总量

scard key

判断集合中是否包含指定数据

sismember key member

随机获取集合中指定数量的数据

srandmember key [count]

随机获取集合中的某个数据并将数据移出集合

spop key [count]

扩展操作

求连个集合的交集＼并集＼差集

sinter key1 [key2 …]
sunion key1 [key2 …]
sdiff key1 [key2 …]

求两个集合的交、并、差集并存储到指定集合中

sinterstore destination key1 [key2 …]
sunionstore destination key1 [key2 …]
sdiffstore destination key1 [key2 …]

将指定数据从原始集合中移动到目标集合中

smove source destination member

注意事项

• set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份
• set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间

应用场景

场景描述

黑名单

资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术， 快速获取信息，个别特种行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售。例如第三方火车票、机票、酒店刷票代购软件，电商刷评论、刷好评。

同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用。

ps:不是说爬虫一定做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量。

白名单

对于安全性更高的应用访问，仅仅靠黑名单是不能解决安全问题的，此时需要设定可访问的用户群体， 依赖白名单做更为苛刻的访问验证。

解决方案

基于经营战略设定问题用户发现、鉴别规则

周期性更新满足规则的用户黑名单，加入set集合

用户行为信息达到后与黑名单进行比对，确认行为去向

黑名单过滤IP地址：应用于开放游客访问权限的信息源

黑名单过滤设备信息：应用于限定访问设备的信息源

黑名单过滤用户：应用于基于访问权限的信息源

实践案例

描述

使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示？

解决方案

依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用

对置顶与普通会话分别创建独立的list分别管理

当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）

多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id

推送消息时先推送置顶会话list，再推送普通会话list，推送完成的list清除所有数据

消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

Zset(sorted set)

有序的set集合

基本命令操作

添加

zadd k source v [source v]....
# 举例
zadd aa 10 v1 20 v2 2 v3

遍历

zrange k start end [withscores]
# 说明 
start 开始下标(最小为0)
end 结束下标(为-1时遍历全部)
withsocres 有该参数显示添加时的排序顺序

反转(与遍历相同的使用方法,返回顺序相反)

zrevrange v start end [withscores]

根据添加时的排序顺序查询

zrangebyscore k min max [withscores] [limit num]
# 说明 
min 最小顺序(当顺序左方加 ( 说明不包含该数字)
max 最大顺序(当顺序左方加 ( 说明不包含该数字)
withsocres 排序字段是否显示
limit 过滤几个

获取元素的排序数字

zscore k v

获取集合中元素的数量

zcard k

删除元素

zrem key k

增加某元素的排序数字

zincrby k num v

获取指定排序数字范围内的个数

zcount k min max

获取元素的下标值

zrank k v

逆序下的元数下标值

zrevrank k v

应用场景

打赏榜单
商品的销售榜单

bitmap

由0和1状态表现的二进制的bit数组

基本操作

添加元素

setbit k num v(0/1)

获取元素

getbit k num

获取某key占用字节大小(一个字节8位)

strlen k

获取某key中1的个数

bitcount k

应用场景

用户是否登录过(比如京东每日签到送京豆)
电影,广告是否被点击播放过
钉钉打卡上下班,签到统计

HyperLogLog基数统计

去重统计功能的基数估计算法,但只会根据输入元素来计算基数,不会存储输入元素本身

基本操作

添加元素

pfadd k v [v....]

获取元素个数

pfcount k

将多个k复制到新的k

pfmegre tk sk1 sk2

应用场景

统计某个网站的UV
统计某个文章的UV
用户搜索关键词的数量
统计用户每天搜索不同词条个数

GEO地理空间

基本操作

添加经纬度坐标

geoadd k 经度 纬度 建筑物名称(可以中文)

返回经纬度

geopos k 建筑物名称

返回经纬度的geohash表示

geohash k 建筑物名称

俩个位置之间的距离

geodist k 建筑物名称 建筑物名称 单位(km/m)

以半径为中心,查找附件的建筑物

georadius k 经度 纬度 半径 单位(km/m) [withdist] [withcoord] [withhash] [count num] desc  
# 说明
withdist 再返回位置元素的同时,将位置元素与中心之间的距离一并返回.距离的单位和给定的范围单位保持一致
withcoord 将位置元素的经纬度一并返回
withhash 以52位有符号整数的形式, 返回位置元素经过原始geohash编码的有序集合分值.主要用于底层应用或调试
count 限定返回的记录数

以半径为中心,查找附件的建筑物

georadiusbymember k 建筑物名称 半径 单位(km/m) [withdist] [withcoord] [withhash] [count num] desc

应用场景

某一坐标多少半径内的建筑物
美团地图位置附件的酒店推送
高德地图附近的核酸检查点

Stream

redis版的消息中间件

字段	说明
Message Content	消息内容
Consumer group	消费组, 通过XGROUP CREATE命令创建, 同一个消费组可以有多个消费者
Last_delivered_id	游标, 每个消费组会有个游标last_delivered_id, 任意一个消费者读取了消息都会使游标往前移动
Consumer	消费者, 消费组中的消费者
Pending_ids	消费者会有一个状态变量, 用于记录被当前消费已读但为ack的消息ID, 如果客户端没有ack, 这个变量里的消息ID会越来越多, 一但某个消息呗ack它就开始减少. 这个pending_ids变量再redis官方呗称之为PEL(Pending Entries List), 记录了当前已经被客户端读取的消息, 但还没有ack(Acknowledgecharacter: 确认字符), 它用来确保客户端至少消费了消息一次, 而不会在网络传输中丢失没处理

基本操作

添加

xadd k * filed value [filed value...]
# 说明
* 表示服务器自动生成MessageID (毫秒-第几条消息), 后面的ID不得小于前面的ID

获取消息

xrange k start end count
# 说明 
start 表示开始值, - 表示最小值
end 表示结束值, + 代表最大值
count 表示最多获取多少个

反转(同上面的获取消息)

xrevrange k end start count

删除

xdel k id [id...]

获取某k下面消息的个数

xlen k

对某k 下面的键值对进行截取

xtrim k maxlen num # 允许的最大长度, 对消息个数进行限制
xtrim k minid id # 允许的最小ID, 从某个ID值开始,比该ID值小的将会被抛弃

读取消息

sread [count num] [block milliseconds] streams k [k...] id [id...]
# 说明
count 最多读取多少条消息
block 是否已阻塞的方式读取消息, 默认不阻塞, 如果milliseconds设置为0, 表示永远阻塞
id 为&符时,读取已存储的最大的ID后的ID,当Stream中不存在大于当前最大的ID消息时,返回nil
   为0-0代表从最小的ID开始获取消息,不指定count时,将返回Stream中的所有消息,也可以使用0/00/000...

创建消费组

xgroup create k 组名称 id(&/0)
# 说明
$ 从尾部开始消费(大于当前最大的id)
0 从头开始消费
创建消费组的时候必须指定id

消费组的消费者消费消息

xreadgroup group 组名称 消费组名称 [count num] streams k > 
# > 表示从第一条尚未呗消费的消息开始读取 没有指定count 数量时,消费k中的所有消息

查看已消费但未确认的消息

xpending k 组名称 [start] [end] [count] [consumer]

确认消息

xack k 组名称 id [id...]

通用操作

key的通用操作

key是一个字符串，通过key获取redis中保存的数据,我们可以通过一些命令对key状态＼有效性＼快速查询　进行控制。

对于key自身状态的相关操作，例如：删除，判定存在，获取类型等

对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

对于key快速查询操作，例如：按指定策略查询key

删除操作

del key

判断key是否存在

exists key

判断key对应值的类型

type key

排序

sort key alpha //alpha表示按照顺序输出
sort key alpha desc//降序

有效性

为指定key设置有效期

expire key seconds 
pexpire key milliseconds 
expireat key timestamp
pexpireat key milliseconds-timestamp

获取key的剩余有效时间，失效是负数

ttl key //单位是秒
pttl key//单位是毫秒

切换key从时效性转换为永久

persist key

查询所有的key

keys

查询通配符

• 匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号

db常用指令

问题描述

key是由程序员定义的

redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key

数据不区分种类、类别混杂在一起，极易出现重复或冲突

解决方案

redis为每个服务提供有16个数据库，编号从0到15

每个数据库之间的数据相互独立

命令

切换数据库

select num

其他指令ping,查看服务器是否通畅

ping

移动

move key db //把ｋｅｙ移动到其他ｄｂ

查看当前库中的数据总数

dbsize

数据清除

flushdb　//清除当前库
flushall　//全部清除

持久化

自动备份概念

持久化概念

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化持久化用于防止数据的意外丢失，确保数据安全性

持久化过程保存什么

将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

RDB持久化方案

save指令

配置redis.conf

[重要] 设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

[重要] 设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险

rdbchecksum yes|no

使用命令添加或修改数据,然后执行save,将数据持久化到硬盘

set name jack
save

原理

执行save指令时会阻塞，无法执行其他任何操作

bgsave指令

操作步骤

1. 配置redis.conf
   后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

   stop-writes-on-bgsave-error yes|no
   

2. 手动启动后台保存操作，但不是立即执行 ，开启子线程执行保存数据操作，所以主线程不会阻塞

   bgsave
   

原理
bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

自动保存

原理

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

操作步骤，直接修改配置文件即可

1. 修改配置文件redis.conf

格式　save second changes

second：监控时间范围

changes：监控key的变化量

save 900 1
save 300 10
save 60 10000

6.0.14版本及以下 conf配置文件中的默认配置

原理
save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的save配置启动后执行的是bgsave操作

三种区别

bgsave是主流

RDB持久化的启动方式

# 重启服务器也会持久化数据
debug reload

# 关闭服务器时保存数据
shutdown save

RDB优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多

应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

RDB的优化设置

配置	默认参数	说明
stop-writes-on-bgsave-error	yes	如果配置成no,表示 不在乎数据不一致或其他手段发现和控制这种不一致,name在快照写入失败时,也能确保redis继续接受新的写的请求
rdbcompression	yes	对于存储到磁盘中的快照, 可以设置是否进行压缩存储, 如果是的话, redis会采用LZF算法进行压缩. 如果不想消耗CPU来进行压缩的话, 可以关闭此功能.
rdbchecksum	yes	在存储快照后, 还可以让redis使用CRC64算法来进行数据校验, 但这会增加大约10%的性能消耗, 如果希望获取到最大的性能提升, 可以关闭此功能,
rdb-del-sync-files	no	在没有持久性的情况下删除复制中使用的RDB文件启用.

AOF持久化方案(主流)

RDB弊端

存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低

大数据量下的IO性能较低

基于fork创建子进程，内存产生额外消耗

宕机带来的数据丢失风险

解决思路

不写全数据，仅记录部分数据

降低区分数据是否改变的难度，改记录数据为记录操作过程

对所有操作均进行记录，排除丢失数据的风险

概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

redis6 配置

修改redis.conf

# 开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no

# AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename

# AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir

# AOF写数据策略，默认为everysec，推荐使用默认
appendfsync always|everysec|no

redis7 配置

修改redis.conf

# 开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no

# AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename

# AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir
# 会在dir路径后添加appendonlydir文件夹,在该文件夹下创建aof文件
appenddirname "appendonlydir"

# AOF写数据策略，默认为everysec，推荐使用默认
appendfsync always|everysec|no

redis7创建的aof文件

文件格式	文件类型	文件说明
base	基础文件	由子进程通过重写产生, 该文件最多只有一个
incr	增量文件	在AOFRW开始执行时被创建, 该文件可能存在多个
manifest	清单文件	跟踪,管理aof文件
history	历史aof	由base和incr aof变化而来, 每次AOFRW成功完成时,本次AOFRW之前对应的base和incr aof都将变为history, history类型的aof会被redis自动删除

AOF三种写入策略(写回策略)

always(每次）：每次写入操作均同步到AOF文件中，数据零误差，IO频率高, 性能较低，不建议使用。

everysec（每秒，推荐）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据, 数据准确性较高，性能较高，建议使用，也是默认配置

no（系统控制）：由操作系统控制每次同步到AOF文件的周期, 整体过程不可控

AOF优势

• 使用AOF Redis 更加持久: 您可以有不同的 fsync 策略: 根本不fsync、每秒 fsync、每次查询时 fsync。使用每秒 fsync 的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有 fsyne 正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入数据。
• AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即便由于某种原因 (磁盘已满或其他原因) 日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它。
• 当AOF 变得太大时，Redis 能够在后台自动重写AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
• AOF 以易于理解和解析的格式依次包含所有操作的日志。您甚至可以轻松导出AOF 文件。例如，即使您不小心使用该FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存您的数据集.

AOF缺点

• AOF 文件通常比相同数据集的等效 RDB 文件大。
• 根据确切的 fsync 策略，AOF 可能比 RDB 慢。一般来说，将 fsync 设置为每秒性能仍然非常高，并且在禁用 fsyne 的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB 仍然能够提供关于最大延迟的更多保证.

Redis7—AOF文件重写(当AOF文件大小超出阈值进行文件重写)

自动

配置文件(默认配置)

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 同时满足, 且的关系才会触发
# 1. 根据上次重写后的aof大小, 判断当前aof大小是不是增长了1倍
# 2. 重写时满足的文件大小

手动

向服务器发送bgrewriteao命令

重写原理

1. 在重写开始前，redis会建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2. 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3. 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4. 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5. 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF 文件重写触发机制: 通过 redis.conf 配置文件中的 autoaof-rewritepercentage: 默认值为100，以及auto-aof-rewritemin-size: 64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

优化

AOF重写

redis会把以上三个操作合并成一个。这个叫做重写.随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

aof重写作用

降低磁盘占用量，提高磁盘利用率

提高持久化效率，降低持久化写时间，提高IO性能

降低数据恢复用时，提高数据恢复效率

aof重写规则

1. 进程内具有时效性的数据，并且数据已超时将不再写入文件
2. 非写入类的无效指令将被忽略，只保留最终数据的写入命令
   如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
   ​ 如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
3. 对同一数据的多条写命令合并为一条命令
   如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
   为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

vaof重写方式

1. 手动重写，执行以下命令

bgrewriteaof

2. 自动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage　# 百分比

重写流程

RDB PK AOF

对数据非常敏感，建议使用默认的AOF持久化方案

• AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。

• 注意：由于AOF文件存储体积较大，且恢复速度较慢

数据呈现阶段有效性，建议使用RDB持久化方案

• 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
• 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：

综合比对

• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
• 灾难恢复选用RDB
• 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量