Redis设计与实现(三) 分布式和独立功能部分 事务 ,慢查询日志 和 监视 (本系列完结)

Redis设计与实现

第一部分 数据结构与对象

Redis对象

• 首先key value,key是固定的字符串对象,value可以是那5种中的一种,而那5种根据场景的不同,每种都有至少两种编码方式,也就是数据结构

• 数据结构有linkedlist 双端链表

• ziplist压缩列表

  • 这个用的太多了 以至于我有深刻的印象

• skiplist

  • 跳跃表 类似于平衡树的作用 但是实现方式太友好了

• raw

  • 都是sds simply dynamic string

• embstr

  • 都是sds simply dynamic string 区别是这个更短喽 压缩过的 是连续的内存 所以速度比raw的快

• hashtable

  • 两个表嘛ht[0]和ht[1]
  • 嗯 冲突就是在同一个哈希值组成链表 然后有一个负载因子 默认好像是1 进行rehash 然后rehasn的话会在另外一个大于当前数量number的最小的2的n次方那么大的扩容 扩容期间 服务器空闲就转移 当然 新插入的都是在这个新表里 hashtable数组ht[1] 然后全部拷到ht[1]后 就会把ht[0]换成ht[1] 然后h[1]又变成空

• linkedlist

  • 就是一个简单的双链表

• intset

  • int_8 int_16 int_32 int_64
  • 会保存编码方式
  • 一旦有东西需要往上提 比如从int_32到int_64了 这个过程是不可逆的 即使把64的都删了 也不会降编码回32了

第八章 对象

• 字符串

  • int

    • redis默认有0~9999的int字符串
    • 顺便说一下 整数都是先转字符串 然后用的时候再转回数字

  • raw

  • embstr

• 列表

  • linkedlist
  • ziplist

• 哈希对象

  • ziplist
  • dict 或者叫hashtable

• 集合

  • intset
  • hashtable

• 有序集合

  • ziplist

    • score key

  • 数据结构叫zset

    • skiplist

      • 子主题 1

    • dict

      • 子主题 1

    • 同时用这两个的原因是因为 既要单点查询的速度 也要范围查询的速度吧

第二部分 单机数据库的实现

第9章 数据库

• 类型检查 命令多态

  • 先看key是不是符合那个命令的

    • 再看看编码方式是什么

• 对象回收

  • 计数呗

• 对象共享

  • 不共享包含字符串的对象

  • 对整数检查O(1)

  • 对字符串O(N)

  • 对象包含了多个值对象

    • O(N^2)

• 空转时长

  • 有个lru时间 记录最后一次被程序访问的时间

第10章 RDB持久化

第11章 AOF持久化

第12章 事件

第13章 客户端

第14章 服务器

第三部分 多机数据库的实现

第15章 复制

• Redis的复制分为两步, 同步(sync)和传播(command propagate)

  • 在我理解无非一个是先获取一个服务器的快照
  • 另外一个是追赶式恢复

• 1.同步

  • 客户端向服务器发送SYNC命令来完成

    • 1.从服务器向主服务器发送SYNC命令
    • 2.收到SYNC的master执行 BGSAVE命令, 在后台生成一个RDB文件, 并用一个缓冲区来记录现在开始的所有命令
    • 3.主服务器把RDB文件传给从服务器,从服务区更新至 主服务器执行BGSAVE的命令状态
    • 4.主服务器把缓冲区的所有命令发送给从服务器, 从服务器进行追赶式恢复

  • SYNC命令非常号资源,

    • 生成RDB文件需要CPU 内存, 磁盘I/O
    • 发送RDB文件需要网络带宽
    • 从节点载入的时候也无法处理请求

• 2.命令传播

  • 无非就是主服务器执行命令 , 然后发送给 从服务器 来保持一致性

• 旧版复制功能的缺陷

  • 每次都是把完整的RDB文件进行传输

    • 如果断线时间不是很长也要 全部复制一遍
    • 所有要引入部分复制(PSYNC)

• 新版复制功能

  • 部分重同步的实现

    • 1.主服务器的复制偏移量(replication offset)

      • 主服务器和从服务器都维护一个偏移量

        • 每次主服务器向从服务器传播N个字节的数据,就把字节的偏移量加上N
        • 从服务器收到N个字节的数据, 也把自己的偏移量加上N
        • 如果二者偏移量不一样, 那就是数据不一致

    • 2.主服务器的复制挤压缓冲区(replication backlog)

      • 是一个固定长度的先进先出队列

        • 如果从服务器连接上主服务器的时候, 从服务器会把自己的偏移量发给服务器

          • 如果已经不在了

            • 执行完整的重同步

          • 如果这个偏移量还在复制积压缓冲区之内

            • 执行部分同步

        • 默认1MB

          • 一般设成= 2(冗余)* 平均重连时间*每秒写入命令的字节数

    • 3.服务器的运行ID

      • 主服务器会把自己的ID发送给客户端

        • 如果从服务器保存的运行ID和当前的主服务器发过来的一样, 说明之前连的就是这台, 尝试部分重同步
        • 如果不一样, 执行完整重同步

• 复制功能的实现

  • 步骤1 设置主服务器的ip和端口

    • 加上俩机子服务器
    • 异步的, 返回ok, 然后后台执行复制

  • 步骤2 建立socket连接

    • 如果成功连接

      • 从服务器会被主服务器看成特殊的客户端

      • 对于普通的客户端来说

        • 从服务器还是个服务器

  • 步骤3 发送ping命令

    • 如果不成功会回到第2步的

  • 步骤4 身份验证

    • 主要是看主服务器和从服务器有没有设置密码, 常识
    • 失败就重试
    • 成功就准备复制

  • 步骤5 发送端口信息

    • 从服务器向主服务器发送从服务器的监听端口号

  • 步骤6 同步

    • 互为客户端

  • 步骤7 命令传播

    • 进入命令传播状态

      • 一直接受主服务器的写命令

• 心跳检测

  • 命令传播阶段, 每1s ,从服务器会向主服务器发送replication ack [offset]

  • 作用

    • 1.检测主从服务器的连接状态

    • 2.辅助实现min-slaves选项

      • 比如min-slave-to-write 3
      • min-salves-max-lag 10
      • 如果从服务器少于3 , 拒绝写
      • 如果三个服务器延迟都大于等于10, 拒绝写的请求

    • 3.检测命令丢失

      • 如果主服务器发现落后于自己, 就会从复制挤压缓冲区中重新发给从服务器

第16章 Sentinel哨兵

• 现在我知道了,哨兵就是负责监视主服务器和从服务器 然后如果主服务器下线了 它会选出新的从服务器作为主服务器, 然后在原来的主服务器上线后把它降级成从服务器

• 哨兵是Redis的高可用性解决方案

  • 由一个或多个哨兵组成的哨兵系统可用监视任意多的服务器

• 启动并初始化Sentinel

  • 初始化服务器

  • 使用Sentinel专用代码

  • 初始化Sentinel状态

  • 初始化Sentinel状态的masters属性

  • 创建连接向主服务器的"异步"网络连接

    • 一个是命令连接

      • 用来发送命令 和 接受回复

    • 一个是 订阅连接

      • sentinel:hello频道

• 获取主服务器信息

  • 每10s一次 发送INFO命令

    • 可以获取主服务器和 它的从服务器的信息

• 获取从服务器信息

  • 会创建到从服务器的命令连接和订阅连接

• 向主服务器和从服务器发送信息

  • 向__sentinel__:hello 频道发送信息 s_开头的是 sentinel本身的信息, m_开头的是 主服务器的信息

• 接受来自主服务器和从服务器的频道信息

  • 如果有3个sentinel监视同一个服务器 , 三个sentinel都会收到 sentinelA发送的频道信息

  • 如果发现是自己的信息, 就丢弃

  • 如果发现是其他sentinel, 就更新信息, 也会保存其他sentinel

    • 然后会创建连向其他sentinel的命令连接

• 检测主观下线状态

  • 默认情况,sentinel 会向 所有的 "命令连接" 发送PING命令(包括主服务器, 从服务器, 其他Sentinel

  • 有效回复

    • +PONG
    • -LOADING
    • -MASTERDOWN

  • 无效回复

    • 除那三个以外的
    • 或者无回复

  • 50000ms

    • 会用来判断 主服务器, 从服务器 ,以及所有监视主服务器的Sentinel的状态, 这些人 都是50s没回复, 本宝宝就认为你们下线了

• 检测客观下线状态

  • 会问其他Sentinel,看他们是否认为下线了
  • 当认为下线的Sentinel达到一定数量, 我们会标记成客观下线状态

• 选举领头Sentinel

  • 当Amaster下线后, 监视他的所有Sentinel会 选出一个领头Sentinel, 并由这个领头Sentinel来负责故障转移操作
  • 然后会在一个配置纪元里选出领头Sentinel
  • 选不出就继续选
  • Raft算法

• 故障转移

  • 选出新的主服务器

    • 领头Sentinel向它选择的从服务器 发送SALVE no one, 然后每秒发一次INFO, 直到从slave变成 master

  • 修改从服务器的复制目标

    • 向其他的从服务器发送SLAVEOF命令

  • 将旧的主服务器变成从服务器

第17章 集群

• Redis集群是Redis提供的分布式数据库方案, 集群通过分片(sharding)来进行数据共享, 并提供复制和故障转移功能

• 节点

  • 启动节点

    • 一个节点就是一个运行在集群模式下的Redis服务器

    • 一个节点会继续做所有单机模式中使用的服务器组件

      • 1,会继续使用文件事件处理器来处理命令请求和返回命令回复

      • 2,继续使用时间事件处理器来执行serverCron函数, 还会调用clusterCron函数

        • clusterCron函数负责执行在集群模式下的常规操作

          • 1,向其他节点发Gossip信息
          • 2,检查节点是否断线, 检查是否需要对下线节点进行自动故障转移等等

      • 3,继续数据库

      • 4, 继续RDB和AOF持久化模块

      • 5,继续使用发布/订阅模块

      • 6,继续使用复制模块

      • 7,继续使用Lua脚本

    • CLUSTER MEET命令的实现

      • 客户端发 CLUSTER MEET命令给节点A, 让节点A和节点B握手

        • 节点A发送MEET消息
        • 节点B发送PONG消息
        • 节点A发送PING消息

• 槽指派

  • 集群通过分片的方式来保存 数据库的 键值对

    • 整个数据库被分为16384个槽, 只有这16384个槽都有节点处理 的时候, 集群才是上线状态的

  • 记录节点的槽指派信息

    • slots属性是一个二进制位数组(bit array)

      • 如果索引i上的二进制位的值位1, 表示处理槽i
      • 如果索引i上的二进制值位0 , 表示不处理i

    • 所以检查是否负责处理某个槽, 或者任命某个槽

      • 时间复杂度为O(1)

  • 传播节点的槽指派信息

    • 节点会向其他节点发送自己的slots数组

  • 记录集群所有槽的指派信息

    • clusterState.slots数组记录了所有 具体的槽 map到具体节点的信息
    • clusterNode记录了某个节点的槽指派信息

  • CLUSTER ADDSLOTS命令的实现

• 在集群中执行命令

  • 客户端向节点发送数据库的命令时, 接受命令的节点会算出 key属于哪个槽 ,这个槽又是否属于自己

  • 计算键属于哪个槽

    • CLUSTER KEYSLOT

      • 可以看给定的key属于哪个槽
      • CRC16(key)& 16383

  • 判断槽是否由当前节点负责处理

    • 看hashtable是不是指向自己

  • MOVED错误

    • MOVED :

  • 节点数据库的实现

    • 会开一个跳跃表来保存 槽与键的 关系
    • 便于对属于某个或者某些槽的所有数据库键进行批量操作

• 重新分片

  • 重新分片可以将任意数量 已经分派给A的 槽 改成 分派给B的

  • 可以在线进行, 并且可以继续处理命令请求

  • 重新分片的实现原理

    • 由Redis集群管理软件redis-trib负责进行的

    • 相当于一个controller

      • 对目标节点发送准备导入
      • 源节点准备迁移
      • 迁移

• ASK错误

  • 具体步骤

    • 客户端 向源节点 发送关于key的命令

    • 在 源上, 执行命令

    • 不在源上 正在迁移?

      • 在迁移, 返回ASK错误
      • 不在迁移 返回key不存在

  • ASK错误和MOVED错误的区别

    • 都会导致客户端转向
    • MOVED 以后都会发给新的
    • ASK 只是临时的

• 复制与故障转移

  • Redis中的节点分为主节点(master)和从节点(slave), 主节点用于处理槽 , 从节点用于复制某个主节点

  • 设置从节点

    • CLUSTER REPLICATE <node_id>

  • 故障检测

    • 子主题 1

  • 选举新的主节点

    • Raft算法

• 消息

  • 主要有5种消息

    • MEET
    • PING
    • PONG
    • FAIL
    • PUBLISH

第四部分 独立功能的实现

第18章 发布与订阅

• 发布与订阅的核心命令是两组

  • Publish

  • Subsctibe

    • Subscribe
    • UnSubscribe
    • PSubscribe
    • PUnSubscribe

• 1.频道的订阅与退订

  • 订阅频道

    • 服务器有个字典叫pubsub_channels

      • 键是 某个被订阅的频道
      • 值是 一个链表, 这里面存了该频道的订阅者

  • 退订频道

    • 根据频道的名字在字典中找

      • 把客户端从链表中删除
      • 如果恰好是最后一个, 把这个频道也删除

• 2.模式的订阅与退订

  • 服务器有个list叫pubsub_patterns

    • <client, pattern>作为list链表的元素
    • list<client,pattern>

  • 订阅模式

    • 新建一个node, 把这个node添加到list后面

  • 退订模式

    • 遍历这个list, 找到node然后删掉

• 3.发送消息

  • 发送消息publish channelA "message"有两步,

    • 1.首先把消息发给channelA的所有订阅者
    • 2.然后把消息发给所有模式匹配channelA的

  • 1.很简单啦, 找到key对应的链表, 然后全部发一遍

  • 2.先查找所有list里的pattern, 如果匹配, 就把这个pattern对应的client都发一遍

• 4.查看订阅消息

  • pubsub channels

  • pubsub numsub [channel]

    • 返回channel的订阅者数量

  • pubsub numpat

    • 返回被订阅模式的数量
    • number of pattern

第19章 事务

• Redis以MULTI命令开始, + 多个命令 +EXEC 提交给服务器来执行一个事务, 同时搭配上 WATCH命令, 来实现事务功能

• 事务的实现

  • 三个阶段

    • 1.事务开始

      • 会把客户端从非事务状态切换成事务状态

    • 2.事务入队

      • 在非事务状态, 命令会立即执行

      • 在事务状态, 会看具体是啥命令

        • EXEC, DISCARD, WATCH, MULTI四个命令会立即执行
        • 其他命令放入一个队列, 返回QUEUED回复

    • 3.事务执行

      • 遍历这个队列, 依次执行

• WATCH命令的实现

  • WATCH命令是一个乐观锁, 它可以在EXEC命令执行前 ,监视任意数量的数据库键, 并在EXEC命令执行时, 检查被监视的键是否至少有一个已经被修改了, 如果被改了, 服务器拒绝执行事务

  • 使用WATCH 命令监视数据库键

  • 监视机制的触发

    • 所有对数据库进行修改的命令, 都会对监视的数据结构(字典)进行检查, 如果匹配, 置安全性的标志位被破坏

  • 判断事务是否安全

    • 看一下安全性的标志位

  • 一个完成的WATCH事务 执行过程

• 事务的ACID性质

  • 原子性

    • Redis不支持事务回滚机制(rollback)

      • 某个命令在执行期出现错误, 整个事务也会继续执行
      • 因为这种错误一般在开发环境, 很少在生产环境

  • 一致性

    • 入队错误

      • 入队出错, 其他成功入队的命令依旧正常执行

    • 执行错误

    • 服务器停机

      • 1.如果运行在无持久化的内存模式下, 重启后是空白的, 所以是一致性的
      • 2.有RDB文件, 也可以恢复到一致状态
      • 3.AOF, 也可以恢复到一致状态

  • 隔离性

    • 因为Redis使用单线程的方式来执行事务, 并且服务器保证 不会中断事务, 总是串行的方式运行, 所以事务也是有隔离性的

  • 持久性

    • 1.在内存模式下, 不具有持久性
    • 2.在RDB, 只有特定条件下, 才会执行BGSAVE命令, 而且异步的BGSAVE也不能保证事务第一时间保存在硬盘里, 也不具有持久性
    • 3.AOF模式, 且配置为always的时候, 同步的, 所以这有持久性
    • 4,AOF, 非always, 不具有持久性

第20章 Lua脚本

• 通过在服务器中嵌入Lua环境,Redis客户端可以使用Lua脚本, 直接在服务器端原子地执行多个Redis命令

第21章 排序

第22章 二进制位数组

第23章 慢查询日志

• Redis的慢查询日志功能用于记录执行时间超过给定时长的命令请求, 用户可以通过这个功能产生的日志来监视和优化 查询速度

• 服务器配置有两个选项

  • slowlog-log-slower-than

    • 这个选项为100, 执行超过100微秒的命令就会被记录

      • CONFIG SET slowlog-max-len 5
      • SLOWLOG GET

  • slowlog-max-len

    • 最多保存多少条慢查询日志

• 慢查询记录的保存

  • 用一个链表, 新的在表头

• 慢查询纪录的阅览和删除

• 添加新日志

  • 每次执行命令前, 都记录一下Unix时间戳, 执行完后, 也记录一下Unix时间戳

  • 检查有没有超出slowlog-log-slower-than
    的时间

  • 检查有没有超链表的长度

    • 有就删

第24章 监视器

• 客户端可以通过MONITOR命令 ,将客户端转换成监视器 ,接受并打印每个命令请求的相关信息
• 把客户端的REDIS_MONITOR标识打开, 就可以从普通客户端变成监视器了
• 服务器把所有监视器都存在一个链表里
• 每次都会遍历链表, 挨个发送

实践

Redis的入门应用

• Redis是key-value型数据库

• Redis 里的单行命令都是原子的 是为了同时有多个用户对同一个数据修改

• string

  • set key value

    • 子主题 1

      • SET server:name "fido"
        

      • GET server:name => "fido"
        

      • EXISTS server:name => 1
        

      • EXISTS server:blabla => 0
        

      • SET connections 10
        

      • INCR connections => 11
        

      • INCR connections => 12
        

      • DEL connections
        

      • INCR connections => 1
        

      • It is also possible to increment the number contained inside a key by a specific amount:
        

      • INCRBY connections 100 => 101
        

      • And there are similar commands in order to decrement the value of the key.
        

      • DECR connections => 100
        

      • DECRBY connections 10 => 90
        

  • get key

  • exists key

  • DEL key

  • EXPIRE key 100

    • 100秒后删除

    • TTL key

      • 显示还有几秒删除
      • 只要set key 一次 之前的计时失效 TTL key 返回-1
      • 返回-2说明计时过了 这东西被删了

    • PERSIST key

      • 让这个计时结束

        • 永久保存

  • INCR key

    • INCRBY key 100

  • DECR key

    • DECRBY key 100

  • 不能简单的get key value=value+1 set key value

• list

  • 对头尾操作较快 且 有序号的

  • lpush friend "yanhao"

    • rpush friend "yanhao"

    • lpush friend 1 2 3 4

    • 执行顺序是

      • lpush friend 1
      • lpush friend 2
      • lpush friend 3
      • lpush friend 4

    • 所以结果是 4 3 2 1

  • lrange friend 0 -1

    • 切片

    • example

      • LRANGE friends 0 -1 => 1) "Sam", 2) "Alice", 3) "Bob"

      • LRANGE friends 0 1 => 1) "Sam", 2) "Alice"

      • LRANGE friends 1 2 => 1) "Alice", 2) "Bob"

      • lrange friend 0 10

        • 1. "Sam", 2) "Alice", 3) "Bob"

      • lrange friend -3 -1

        • 1. "Sam", 2) "Alice", 3) "Bob"

  • lset friend 0 "yanhao"

    • 把friend这个list里面的第0个元素改成"yanhao"

  • lpop friend

    • rpop friend
    • 子主题 2

  • llen

• set

  • sadd setname "yanhao"

    • return 0

      • 没加成功,因为本来就有这个key了

    • return 1

      • 加成功了

  • sismember setname "yanhao"

  • smembers friend

  • sincr

  • sdecr

  • srem friend "yanhao"

    • return 0
    • return 1

  • srandmeber friend 2

    • 随机返回数据成员

  • spop

    • 随机删

  • sunion set1 set2

• sorted set

  • 在set的同时加上一个用来排序的东西

  • ZADD fruit 1 apple

  • ZADD fruit 2 banano

  • Zrange fruit 0 1

    • 切片

• hashes

  • hset user:37 name "yanhao"

  • hgetall user:37

  • hmset user:37 name "yanhao" age 17

    • 同时设置多个

  • hget user:37 name

  • hincrby user:37 name 2

    • name会加2

  • hdel

XMind: ZEN - Trial Version