读书笔记 《Redis开发与运维 》
Redis使用场景
- 作为缓存层 减少对Mysql的压力
- 计数功能 比如使用原子命令incr
- 共享Session
- 设置过期时间 可以限制短信接口等调用
- 使用hash类型存储一些关系型数据库表中的数据 如用户信息 可以通过表名+id的方式
- 列表类型的数据 可以用来模拟队列或者栈 或者最新的新闻信息等
- 实现发布、订阅
命令执行过程
Redis使用了单线程架构和IO多路复用模型来实现高性能内存数据库服务
- 1.发送命令
- 2.排队
- 3.执行命令
- 4.返回命令执行结果
Pipeline
由于网络或者连接redis服务端比较占用很多时间 redis提供Pipeline机制来加快Redis对数据的操作 它通过一组Redis命令进行组装 通过一次RTT传输给Redis 再将这组Redis命令的执行结果按照顺序返回给客户端
事务
Redis提供简单的事务功能 将一组要执行的命令放到multi和exec两个命令之间 multi代表事务开始 exec代表事务结束
如果执行事务的时候出错，语法级别的错误 将会导致事务回滚 命令不会被执行
如果是运行时错误 则Redis不会回滚
锁
redis提供了watch命令 来确保事务中的key没有被其它应用修改过
持久化
支持RDB和AOF两种持久化机制 AOF持久化开启之后且存在AOF文件则会优先加载AOF文件 否则加载RDB文件
RDB
将当前进程数据生成快照保存到硬盘的过程 默认使用LZF算法对生成的RDB文件做压缩 RDB是一个紧凑的二进制文件 代表Redis在某个时间点上的数据快照 适合全备 而且恢复数据比较快
缺点 没办法做到实时持久化、秒级持久化 因为 bgsave 每次运行都需要执行fork操作创建子进程 属于重量级操作
127.0.0.1:6379> bgsave
Background saving started
执行bgsave命令之后 父进程执行fork命令创建子进程 此时父进程是阻塞的 fork完成之后 bgsave命令返回并不再阻塞父进程 可以继续执行其他命令 新生生成的rdb文件会对原有文件进行原子替换
127.0.0.1:6379> lastsave #查看文件最后保存时间
(integer) 1517474265
AOF
以独立日志的方式记录每次写命令 重启时再重新执行AOF文件中的命令达到恢复数据的目的 可以达到数据持久化的实时性 提供了多种AOF缓存策略 由参数 appendfsync控制
appendonly yes #开启AOF功能 默认文件名是 appendonly.aof
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
流程
- 首先将命令追加到aof_buffer中
- AOF缓冲区根据不同的策略将数据同步到磁盘中
- Redis重启之后 如果AOF配置打开 并且存在AOF文件 则优先加载
AOF重写机制
随着命令不断写入AOF 文件会变得越来越大 Redis引入AOF重写机制压缩文件体积 文件重写是Redis进程内的数据进行转化 然后同步到新的AOF文件中 文件变小的原因如下
- 超时的数据不再写入文件
- 旧的del，重复的操作 都不再写入文件 只会保留最终数据的写入命令
- 多条写命令可以合并成一个 比如多次 lpush操作
数据删除策略
删除策略主要有两种 分别是惰性删除和定时删除
- 被动删除 主节点读取数据之后 会判断键是否超时 如果超时 则执行 del命令删除数据
- 主动删除 主节点内部定时会采样部分键 当发现采样的键过期 则执行del命令
复制
slaveof 命令
默认情况下 redis都是主节点 主节点可以有多个从节点 而从节点只能有一个主节点
可以通过slavof的方式配置 且只能在从节点发起 有下面三种方式
- 在配置文件中添加slaveof masterHost masterPort
- redis-server启动命令之后加入 --slaveof masterHost masterPort
- 直接使用命令 slaveof masterHost masterPort
info replication ##命令查看复制的状态
slaveof no one ##断开与主节点的复制关系
复制过程简介
- 保存主节点地址 之后 就直接返回
- 主从建立socket关系 专门用于主从节点建立通信
- 发生ping命令 测试网络且判断当前是否可接受处理的命令
- 权限验证 如果主节点设置了masterauth 则需要密码验证 从节点需要配置 requirepass参数保证与主节点相同的密码才可以通过验证
- 同步数据集 主从直接正常通信之后 如果是首次建立复制关系 则主节点会将所有的数据发送给从节点
Redis集群相关
Gossip协议工作原理
随机向集群内其它节点发送信息 节点彼此不断通讯 交换信息 理论上一段时间之后 所有的节点都会知道集群的完整信息 类似流言蜚语一样传播
- 集群内每个节点都会单独开辟一个TCP连接，通讯端口会在基础端口上加上10000
- 每个节点会在固定时间内 随机向其它节点发送PING消息
- 收到消息的节点 会用PONG消息 作为相应
- 到集群内节点出现故障 新节点加入 主从角色变化 槽位消息变化 都需要不断的通过PING/PONG消息通讯
Gossip消息分类
- PING 用于检测节点是否在线和交换彼此信息 封装了自己和部分其它节点的状态数据
- PONG 当收到PING MEET消息时 座位相应消息 回复给发送方用于确认通信正常 封装了自身状态的数据 也可以通过PONG广播自身状态 来通知集群内其它节点
- FAIL 节点判断集群内另外一个节点下线 会向集群内广播一个FAIL消息
- 数据分区规则采用虚拟槽的方式 所有的键 映射到16384个槽中
- 搭建集群分为三个步骤 准备节点 节点握手 分配槽
故障转移
故障发现是通过消息传播机制来实现的 主要包括 主观下线和客观下线
- 主观下线：节点定时向其它节点发送PING消息 接收节点如果在cluster-node-timeoute时间内回复POONG消息 则认为通信成功 否则会标记该节点有故障 但是某个节点认为另外一个节点不可用 只能代表一个节点的意见可能存在误判
- 客观下线 当某个节点判断另外一个节点主观下线 则故障节点信息会随着PING/PONG消息 在集群内传播 集群内多个节点都认为该节点下线 那么这个故障节点才真正下线 如果持有槽的主节点故障 需要为该节点进行故障转义