1、事务本质

  1. 事务的本质是保证数据的一致性
  2. Redis支持事务(弱事务),基于队列实现
    • 创建一个事务队列
    • 将事务操作都放入队列中
    • 依次执行
  3. 事务处理机制
    • 语法错误
      • 执行exec命令之后直接返回错误,事务队列中所有命令都不会执行
    • 执行错误
      • 错误的命令不会执行,正确的命令正常执行

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

        RDB（Redis DataBase）

  • 手动或复合配置条件时触发,对此刻内存中的数据进行快照并保存在磁盘中,生成一个经过压缩的二进制文件,后缀名.rdb
  • 配置条件如下: ```shell save “” # 不使用RDB存储 不能主从

save 3600 1 #表示3600秒内至少1个键被更改则进行快照。 save 300 100 #表示300秒内至少100个键被更改则进行快照。 save 60 10000 #表示60秒内至少10000个键被更改则进行快照。

进入redis客户端

bin/redis-cli

同步执行,阻塞redis服务线程直到保存完毕

save

异步执行,fork一个和主线程一致的子线程操作RDB文件,非阻塞

bgsave

  1. **bgsave执行原理:**
  3. 1. bgsave ---> redis服务进程 ----> 判断是否存在执行save或bgsave子进程 
  4.    - 存在: 直接返回
  5.    - 不存在: 阻塞时创建子线程
  6.       - 取消阻塞,可以响应其他命令
  7.       - 生成RDB文件
  9. **优缺点:**
  11. - 优点
  12.    - 基于二进制文件完成备份,占用空间少,便于文件传输
  13.    - 自定义规则,数据备份时间灵活
  14. - 缺点
  15.    - 宕机后最后一次快照后的数据会丢失,无法保证数据完整
  16.    - 即使使用bgsave,创建子线程时仍会阻塞Redis服务进程,频繁执行影响系统吞吐率
  17. <a name="YalSy"></a>
  18. ### AOF**（append only file）**
  20. 1. 保存Redis所有写操作到AOF文件
  21. 1. 执行原理:
  22.    1. 客户端发送写命令
  23.    1. redis将写命令保存至缓冲区文件末尾 aof_buf (命令追加)
  24.    1. 写入AOF文件  (文件写入)
  25.    1. 根据策略向磁盘同步 (文件同步)
  26.       - always 每次写入都会将aof_buf缓冲区文件写入AOF文件中并同步到磁盘, 安全性最高  效率最低
  27.       - everysec 每次写入都会将aof_buf缓冲区文件写入AOF文件中,每隔一秒同步到磁盘 安全性中 效率中
  28.       - no 每次写入都会将aof_buf缓冲区文件写入AOF文件中, 同步操作交由系统执行(默认30秒一次) 安全性最低 效率最高
  29. 3. AOF重写优化
  30. ```shell
  31. #当前aof文件大小超过上一次aof文件大小的百分之多少时进行重写。如果之前没有重写过，以
  32. 启动时aof文件大小为准
  33. auto-aof-rewrite-percentage 100
  35. #限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
  36. auto-aof-rewrite-min-size 64mb

3、两种持久化机制对比

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

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

    通过新搭建子服务器 同步复制主服务器数据完成数据备份容灾

image.png
主从复制步骤:

  1. Slave服务启动,主动连接Master,并发送SYNC命令,请求初始化同步.
  2. Master收到SYNC命令后,执行BGSAVE命令生成RDB文件,并缓存该时间段内的写命令.
  3. Master完成RDB文件后,将其发送给所有Slave服务器
  4. Slave服务器收到RDB文件后删除内存中旧的缓存数据,并装载RDB文件
  5. Master在发送完RDB文件后,立即向所有Slave服务器发送缓存中的写命令

主从复制的作用:

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

    5、主从存在问题

6、哨兵模式原理

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

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

9、异常测试

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

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

* 项目中如何使用的？