1. 什么是redis
特点
- 高性能
- 单线程
- 内存
- 支持持久化
- nosql
作用
- 缓存
- 分布式锁
- 分布式唯一键
- 队列
- 会话
redis配置文件
- demonize 是否有守护进程方式启动
- bind redis允许哪个ip可以连接
- protested-mode 保护模式，默认启动；生效条件：
①没有配置bind
②redis没有设置密码
2. redis五大数据类型
2.1 string
2.1.1 通用操作
- set key value
- get key
- del key
- append key value
如果key存在，则在value末尾添加；否则同set - strlen key
返回value长度 - mset k1 v1 k2 v2
- mget k1 k2
- setnx key value
key存在则不set,key不存在则set key value
2.1.2 value为数字类型时
- incr key
- decr key
2.2 list
有序链表，可以用于实现队列，栈等数据结构
2.3 set
无序集合，可以用作微博、微信等关注模型。通过集合的交集实现共同关注、通过差集实现推荐可能认识的人
2.4 zset
有序集合（使用分数排序）
微博热搜等
2.5 hash
存储对象
3. redis持久化
3.1 RDB(默认方式)
原理
redis会fork一个与主进程完全一致的进程(变量，环境变量，程序计数器)，先将数据写入一个临时文件中，待持久化完成之后，使用该临时文件替换原先的持久化文件。整个持久化过程，不会影响到主进程
文件配置
dir 文件目录
dbfilename 文件名字
触发机制
- shutdown时，如果没有aof，会触发
- 配置文件中有配置默认快照策略时
e.g. save 1000 1 1000秒有一次写操作，则执行快照操作 - 手动执行save或bgsave时
save：已主进程方式进行持久化，所有线程阻塞
bgsave：fork一个子进程来负责持久化操作，阻塞只会发生在 fork子进程的时候 -
flushall 无意义
bgsave.png
#文件目录
dir ./
#文件名称
dbfilename rdb.dump
# 快照策略
save 900 1
save 300 10
save 60 10000
save VS bgsave
| save | bgsave | |
|---|---|---|
| IO类型 | 同步 | 同步 |
| 是否阻塞其他操作 | 是 | 否 |
| 优点 | 不消化额外内存 | 不阻塞redis其他命令 |
| 缺点 | 阻塞其他命令 | fork子进程，消息内存 |
3.2 AOF
原理
将redis的所有写操作命令，以append的方式追加到文件中
文件配置
dir 文件目录
appendfilename aof文件名
appendonly 是否开启aof，默认关闭
appendsync 默认触发机制
触发机制
no：操作系统进行数据数据缓存到磁盘（快，持久化没有保证）
always：同步持久化，每次数据变更时，都会持久化到磁盘（慢，安全）
eveerysec：每秒同步一次（默认值，很快，但可能失去1s以内的数据）
aof文件重写
1.原因：当aof文件达到一定大小(配置项)时，redis会调用bgrewriteaof命令对aof文件进行重写，减少文件大小
- 2.重写方式：跟当前内存中的数据生成对应命令，并不需要读取老的aof文件、命令整合
2.配置项
- auto-aof-rewrite-percentage 100
aof文件增长率超过原始的100%时，自动重写aof - auto-aof-rewrite-min-size 64mb
aof文件大小大于该配置时，自动重写aof
aof文件重写
对于上图有四个关键点补充一下：
在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。
为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。
#文件目录
dir ./ 当前路径
#文件名称
appendfilename "appendonly.aof"
#aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 文件重写策略
aof-rewrite-incremental-fsync yes
RDB vs AOF
| 对比项 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 文件大小 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 低 | 相对高，取决于写入策略 |
3.3 混合方式
为了既能像RDB那样快速恢复，又能像AOF那样少丢失数据，在redis4.0之后，支持混合方式持久化，需要开启参数
# aof-use-rdb-preamble yes
在aof重写时，不再是单纯地将内存数据按照RESP格式写入AOF文件，而且将重写这一刻的内存做RDB快照，并将增量数据按照RESP格式写到AOF文件。重写完成之前，该文件并不叫appendonly.aof，重写完成之后覆盖原有的aof文件
混合持久化的aof文件格式.png
4. redis主从同步
全量复制：
- 从节点配置好之后会发生sync，去连接主节点
- 主节点执行bgsave，生产最新的rdb快照
- 主节点将RDB文件发送给从节点
- 从节点把收到的数据持久化，并加载到内存中
-
在bgsave之后产生的增量数据，主节点会缓存在内存中，并将缓存中的数据发给从节点
全量复制.png
如果主从直之间因为某种原因断开连接，则从节点会再次请求连接主节点，在redis2.8版本之前，会再次执行全量复制，在2.8之后，会执行部分复制
主从复制之后，两侧数据会维持一个offset偏移量，当主从断开之后，从节点会再次请求连接主节点，请求同步时，会带上从节点已有数据的offfset，如果主节点的缓存中有该偏移量数据，则直接将该偏移量之后的数据一次性发送给从节点，如果没有，则会触发全量复制
部分复制.png
5.redis高可用
5.1 缓存穿透
概念解释：业务查询时，缓存为命中，流量全部打到数据库的情况
应对措施：
（1）缓存空对象返回，并设置过期时间
如果每次查询的key均不同，且redis中都不存在，会导致redis中出现很多key(如黑客攻击时，使用不同的key扫描)
（2）布隆过滤器
5.2 缓存击穿
概念解释：热点key访问时，缓存数据并不存在，会集中访问DB
应对措施：缓存提前预热；访问DB时，使用分布式锁（eg:setnx）
5.3 缓存雪崩
概念解释：（1）redis中的key集中过期，会导致请求瞬间打到DB （2）redis挂了，服务请求打到DB
应对措施：
（1）对key值设置不同的过期时间
（2）使用redis集群部署或是哨兵模式（现在基本都是使用集群），在redis主节点挂了之后，从节点会通过选取成为主节点，继续提供服务
6.redis开发规范建议
6.1 key设计
- key值建议加上业务特征，防止key冲突
- key不要过长，如果过长，key较多时，内存占用会很大
- key值不要包含特殊字符
6.2 value设计
value尽量不要过大，防止出现bigkey
bigkey危害：
（1）导致redis阻塞
（2）影响网络开销，value过长，网卡带宽被占满，传输效率低
假如一个bigkey约1M，QPS=1000，那么每秒就会产生1000M流量，如果使用千兆网卡，最大传输率为128M/s，相当于每秒才能完成10个左右的请求，性能极差
（3）key尽量设置过期时间，非必要，不要常驻内存
网友评论