11、Redis高级篇

1、事务本质

事务的特性：ACID
事务的目的：执行业务逻辑后的结果保持一致
Redis支持事务：基于队列实现，但该事务是弱事务（伪事务）
Redis开启事务：multi 取消：discard 执行：exec
Redis事务处理机制：
语法错误（编译）：整个队列事务抛弃不执行
执行错误（运行）：有错误的不执行，其余正常执行，同名的会被后来的覆盖
**springboot不能管理redis的事务，因为redis是弱事务，不像是mysql这样的硬事务可被管理

2、持久化方案，原理，有什么问题

Redis有两种持久化方案：
2.1RDB（Redis DataBase）默认存储的方式，基于快照思想，符合自定义规则即可触发，将内存数据按照快照方式、二进制保存到磁盘上。
— RDB触发条件：可自定义触发机制
save “” # 不使用RDB存储 不能主从 # 记忆
save 3600 1 #表示1小时内至少1个键被更改则进行快照。
save 300 100 #表示5分钟（300秒）内至少100个键被更改则进行快照。
save 60 10000 #表示1分钟内至少10000个键被更改则进行快照。
— 两种保存命令：
save 同步处理，阻塞Redis服务进程，此时服务器不会处理任何命令，指导RDB文件保存完毕；
bgsave fork一个和主线程一致的子线程负责操作RDB文件，不会阻塞Redis服务进程
Redis默认使用的是 bgsave 来保存快照数据。
优点：以二进制备份数据，占用空间少；可自定义规则对数据进行备份
缺点：无法保证数据完整性，会丢失最后一次快照后的所有数据；bgsave创建子线程会阻塞Redis服务进程

2.2AOF（Append Only File）：需手动开启，开启后把所有的“写”命令保存到磁盘的AOF文件中
有两个步骤：
1、选择库（0-15 共16个库） 2、保存写的命令

2、执行原理：

AOF触发方式：

3、两种持久化机制对比

1. RDB默认开启，AOF需手动开启。
2. RDB性能优于AOF。
3. AOF安全性优于RDB。
4. AOF优先级高于RDB（混合模式）。
5. RDB存储某个时刻的数据快照，AOF存储写命令。
6. RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF默认使用everysec，每秒保存一次，最多丢失两秒以内的数据。

4、高可用-主从复制的原理

高可用：单位时间内的系统可用性，行业追求5个9，即99.999%，一年不可用时间约5.256分钟

主从复制的作用：

• 读写分离：主写从读，提高服务器的读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

5、主从存在问题

当主库宕机时，就没办法写入数据，并同步给从库了，这时会产生三个问题：
1、主库是否真的宕机了？
2、应该选择哪个从库作为主库？
3、怎么把新主库的相关信息通知给从库和客户端呢？

6、哨兵模式原理

1、监控：哨兵（Sentinel）不断检查主从服务器的状态是否正常；
2、通知：当发现Redis服务器异常，会立马通知运维人员；
3、自动故障迁移：当主库不可用时，哨兵模式会投票选出从库作为主库，要求票数是哨兵数量一半以上，所以通常哨兵集群配置数量为单数，即最少3个
一般会搭建：一主二从三哨兵 Redis架构

7、经典主从集群解决了什么问题，还存在什么问题

经典主从集群解决了：一主二从三哨兵
1、主从集群间可以实现自动切换，可用性更高；
2、数据更大限度防止丢失；
3、解决哨兵的集群高可用问题，减少误判率

目前还存在什么问题：

• 主节点的写能力和存储能力受限

8、高可扩-分片集群的原理

搭建去中心化的分片集群架构，官方建议：至少需要6个redis搭建，三主三从

• 采用哈希槽（Hash Slot）来处理数据和实例之间的映射关系
• 一个切片集群共有 16384 个哈希槽，只给Master分配

根据CRC16算法对每一个key计算哈希值，再存储到对应的主库中，主库再同步数据给从库

9、异常测试*

• 异常关闭主节点，查看集群节点变化和日志
• 结论：对应的从节点升级为主节点

• 恢复主节点，查看集群节点变化

• 结论：会添加到最新的主节点上，成为从节点

• 异常关闭从节点，查看集群状态

• 结论：不影响集群使用，但是可能会存在单点故障问题

• 同时关闭节点的主和从

• 结论：导致整个Redis集群不可用

10、如何实现redis动态的扩缩容

扩容：
1、先添加主节点，在不停止运行的状态下，进行哈希槽的重新分配，其他主节点会各自分出一部分的哈希槽给到新增主节点；
2、再添加从节点，同步主节点中的数据
缩容：
1、先把主从节点上的数据进行迁移；
2、删除从节点；
3、将主节点上的哈希槽分别还给对应的其余主节点，数量一定对的上，即借多少还多少；

11、key过期删除策略？

11.1定时删除

设置键的过期时间的同时，创建一个定时器， 当键到了过期时间，定时器会立即对键进行删除。
该策略对内存空间足够友好， 但对CPU非常不友好，会拉低系统性能，因此不建议使用。

11.2惰性删除

当key过期时，不会自动立马删除，而是当这key被查询时，会先进行判断，当前的key是否过期，过期则删除，并返回null。
惰性删除对CPU足够友好，但是对内存空间非常不友好，会造成大量内存空间的浪费。

11.3定期删除

• 默认每秒运行10次会对具有过期时间的key进行一次扫描，但是并不会扫描全部的key，因为这样会大大延长扫描时间。
• 每次默认只会随机扫描20个key，同时删除这20个key中，已经过期的key。
• 如果这20个key中过期key的比例达超过25%，则继续扫描。

最佳实践：一般采用的是定期删除+惰性删除；

12、内存淘汰策略（内存满后该怎么办？）

• lru：Least Recently Used，它是以时间为基准，删除最近最久未被使用的key。
• lfu：Least Frequently Used，它是以频次为基准，删除最近最少未被使用的key。

不同策略的使用场景

1、Redis只做缓存，不做DB持久化，使用allkeys。如状态性信息，经常被访问，但数据库不会修改。
2、同时用于缓存和DB持久化，使用volatile。如商品详情页。
3、存在冷热数据区分，则选择LRU或LFU。如热点新闻，热搜话题等。
4、每个key被访问概率基本相同，选择使用random。如企业内部系统，访问量不大，删除谁对数据库也不造成太大压力。
5、根据超时时间长久淘汰数据，选择选用ttl。如微信过期好友请求。

13、Redis6.X新特性

1、支持多线程：

• redis6多线程只是用来处理网络数据的读写和协议解析上，底层数据操作还是单线程
• 开启多线程后，是否会存在线程并发安全问题？
  • 不会有安全问题，Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。

2、引入了 ACL：

• 可以给每个用户分配不同的角色来控制权限

3、client side caching客户端缓存
类似浏览器缓存一样

14、缓存灾难问题解决

15、redis5种数据类型的应用场景*

redis共9种数据结构，除以上5种常用的外，还有bitmap、geohash、hyperloglog、streams;