Redis原理及集群相关知识

读书笔记 《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消息 在集群内传播 集群内多个节点都认为该节点下线 那么这个故障节点才真正下线 如果持有槽的主节点故障 需要为该节点进行故障转义