文章目录
- 0. redis与mysql区别
- 1. redis是单线程架构还是多线程架构
- 2. redis单线程为什么这么快
- 3. redis过期key删除策略
- 4. redis主从复制架构原理
- 5. redis哨兵模式架构原理
- 6. redis高可用集群架构原理
- 7. redis持久化之RDB
- 8. redis持久化之AOF
- 9. redis持久化之混合持久化
0. redis与mysql区别
1.数据库类型
MySQL是关系型数据库
Redis是缓存数据库（非关系型数据库）
2.数据存放位置
MySQL：数据存放在磁盘中
Redis：数据存放在内存中
3.支持数据类型
MySQL：数值、日期/时间、字符串
Redis：String、Hash、List、Set、Zset
1. redis是单线程架构还是多线程架构
redis6.0版本之前是单线程，这里的单线程指的是网络IO和键值对读写命令是由一个线程完成的
redis6.0版本之前之后是多线程，这里的多线程指的是在网络IO请求过程中采用了多线程，但是键值对读写命令仍然是单线程的，并且持久化、集群数据同步、异步删除都是由额外的线程完成的。所以redis仍然是线程安全的
2. redis单线程为什么这么快
命令执行基于内存操作，单条命令操作时间是几十纳秒
命令执行是单线程操作，避免了多线程上下文切换开销
高效的数据结构，包括全局Hash表、简单动态字符串、双向链表、跳跃表、整数数组
基于IO多路复用技术，能够保证大量并发下的效率，提高系统的吞吐量
3. redis过期key删除策略
1.惰性删除: key达到过期时间，不会被立即删除，只有当读写到这个已经过期的key时，才会触发惰性删除策略删除该key
2.定时删除: 由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期(默认每100ms)主动淘汰一批已过期的key,这里的一批只是部分过期key,所以可能会出现部分key已经过期但仍然还没有被清理掉的情况
3.主动删除: 当redis已用内存超过maxmemory限定时，触发主动清理策略，共8种内存淘汰策略
a)针对设置了过期时间的key
1. volatile-ttl: 在设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
2. volatile-random: 在设置了过期时间的键值对，进行随机删除。
3. volatile-lru: 会使用LRU算法筛选设置了过期时间的键值对删除。
4. volatile-lfu: 会使用LFU算法筛选设置了过期时间的键值对删除。
b)针对所有的key
5. allkeys-random: 从所有键值对中随机选择并删除数据。
6. allkeys-lru: 使用LRU算法在所有数据中进行筛选删除。
7. allkys-lfu: 使用LFU算法在所有数据中进行筛选删除。
c)不处理
8. noeviction:不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息，此时Redis只响应读操作。
LRU算法(Least Recently Used,最近最久未使用): 淘汰很久没被访问过的数据，以最近-次访问时间作为参考
LFU算法(Least Frequently Used,最不经常使用): 淘汰最近一段时间被访问次数最少的数据，以次数作为参考
绝大多数情况我们都可以用LRU策略，当存在大量的热点缓存数据时，LFU可能更好点
4. redis主从复制架构原理
常见的主从复制架构：总体来说，主数据库Master以写为主，从数据库Slave以读为主，整体负责读写分离、容灾恢复。
case1：一主二仆【中心化架构】 slaveof 新主库IP 新主库端口
case2：薪火相传【去中心化架构】 slaveof 新主库IP 新主库端口
case3：反客为主 slaveof no one
// 主从数据库数据同步过程
1.全量复制：【当主从服务器刚建立连接的时候，进行全量数据同步】
a、首先从服务器连接到主服务器，发送psync命令进行数据全量同步（Redis2.8之前是sync命令）
b、主服务器收到psync命令之后，执行bgsave命令生成RDB快照文件发送给从服务器
c、从服务器收到RDB快照文件后，清空内存旧数据，将接收到的数据写入磁盘
2、增量复制：【全量复制结束后，进行增量复制】
a、主服务器每执行一个写命令就会向从服务器发送相同的写命令
b、从服务器接收并执行收到的写命令。
优点：
（1）数据热备份：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
（2）故障恢复： 如果master宕掉了，哨兵模式可以提升一个新的master，实现故障转移，达到高可用。
（3）负载均衡： 可以轻易实现横向扩展，实现读写分离，一个master用于写，多个slave 用于分摊读的压力
缺点：
（1）网络延迟：由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟
（2）如果master宕掉了，普通主从模式无法自动切换master，必须使用哨兵模式
5. redis哨兵模式架构原理
优点：可以动态切换主从库，中心型公司首选
缺点：
- 单个master主节点提供写服务，redis存储的数据有限(<10G)，并发量不足(<3w)
- 自动切换主从库会产生访问瞬断的情况，切换没有那么快
工作原理：
哨兵是一个分布式系统，可以在一个架构中运行多个哨兵进程，这些进程使用流言协议(gossip protocols)来传播Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移以及选择哪个Slave作为新的Master。哨兵模式的简单工作原理如下：
（1）监控：哨兵会不断地检查你的Master和Slave是否运作正常。
（2）提醒：当被监控的某个Redis节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。
（3）自动故障迁移：当Master不能正常工作时，哨兵会进行自动故障迁移操作，将其中一个Slave升级为新的Master
6. redis高可用集群架构原理
redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片存储特性
redis集群将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，可线性扩展到上万个节点(官方推荐不超过1000个节点)
redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。
大型公司首选
7. redis持久化之RDB
RDB（Redis DataBase）在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时将快照文件 (dump.rdb) 移动到redis安装目录并启动服务即可。
save 3600 1 # 15分钟变动1次
save 300 100 # 5分钟变动100次
save 60 10000 # 1分钟变动1w次
save save时只管保存，其它不管，全部阻塞。
bgsave Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
RDB优点：
1、持久化速度快：RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。[适合大规模的数据持久化]
2、恢复速度快：与AOF相比，RDB是一个非常紧凑的文件，RDB数据恢复会更快一些
RDB缺点：
1、内存膨胀：Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，大致2倍的膨胀性需要考虑。
2、数据丢失：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
8. redis持久化之AOF
AOF（Append Only File）是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF配置【APPEND ONLY MODE】
appendonly no # 默认no
appendfilename "appendonly.aof" # 文件名
appendfsync [always/everysec/no]
always 同步持久化，redis每次发生数据改变都会被立即记录到磁盘，性能较差但数据完整性最好
everysec 默认推荐，异步操作，每秒记录一次，最多损失1s的数据
no 不进行持久化
no-appendfsync-on-rewrite no # 重写时是否运用appendfsync，默认no即可，保证数据安全性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF优点：
每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
不同步：appendfsync no 从不同步
AOF缺点：
1、文件大、恢复慢：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
2、Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
redis默认使用AOF恢复数据，因为aof保存的数据更全面
9. redis持久化之混合持久化
背景：
- 重启Redis时，我们很少只使用RDB来恢复内存数据，因为这会丢失大量数据
- 通常使用AOF日志重放来恢复数据，但是重放AOF日志性能相对RDB来说要慢很多,当Redis数据很大，启动需要花费很长的时间
Redis 4.0为了解决这个问题，带来了一个新的持久化选项一混合持久化
实现步骤：
步骤一：通过如下配置可以开启混合持久化(必须先开启aof):
aof-use-rdb-preamble yes
步骤二：此时AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB
快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件
步骤三：新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖原有的AOF文件,完成新旧两个AOF文件的替换。
步骤四：redis重启的时候，可以先加载RDB的内容,然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放,因此重启效率大幅得到提升。
