美文网首页
redis 持久化 主从 哨兵 集群等

redis 持久化 主从 哨兵 集群等

作者: laowangv2 | 来源:发表于2020-10-19 23:01 被阅读0次

    1.持久化

    方式

    1. RDB
    2. AOF
    3. RDB+AOF

    RDB vs AOF

    RDB的优缺点
    • 优点
      1. 文件紧凑
      2. 非常适合灾难恢复
      3. 最大化redis性能:fork一个子进程处理
      4. 恢复速度比AOF快
    • 缺点
      1. 本质就是快照,会丢一段时间内的数据
      2. fork可能会耗时较长,造成服务器卡顿
    AOF的优缺点
    • 优点
      1. 本质就是log,最多只会丢一点点数据(取决于fsync策略)
      2. 追加写
      3. AOF重写
      4. 可读性
    • 缺点
      1. 体积大
      2. 可能比RDB慢
      3. 恢复过程中出现bug(如阻塞命令)

    细节

    RDB

    使用方式

    • 配置,如save 60 1000 # 60秒内至少1000个键被改动则触发
    • 手动调用SAVE或者BGSAVE

    流程
    fork一个子进程,将数据写入一个临时RDB文件,写完后替换旧文件

    AOF

    使用方式
    appendonly yes # 配置开启,redis执行的命令会被追加到AOF文件

    重写文件
    手动调用BGREWRITEAOF 或通过配置文件
    重写流程:fork一个子进程,子进程重写到临时文件,父进程将这段时间的命令追加到旧文件的同时积累到内存中,子进程写完后,父进程将内存中积累的命令写入新文件,替换新旧文件

    刷盘策略

    • 每次执行命令都刷盘
    • 每秒
    • 从不,完全由操作系统处理

    文件修复
    redis-check-aof --fix

    2.复制

    使用方式

    • 手动调用SLAVEOF
    • 配置文件

    运作原理

    1. 从服务器发送SYNC命令到主
    2. 主服务器执行BGSAVE,期间的命令保存到内存
    3. 发送rdb文件到从
    4. 发送内存中保存的命令到从

    部分重同步

    需要version >= 2.8,通过PSYNC命令

    1. 主维护生成RDB之后收到的命令到复制积压缓冲区(FIFO队列)
    2. 从维护自己复制的offset
    3. 断线重连后,从发送自己的offset,如果还在复制挤压缓冲区中,则将offset之后的命令发送过来,否则只能执行一次全量的同步,过程同SYNC命令

    注意

    关闭主服务器持久化时,应禁止主服务器的自动拉起

    3.哨兵

    功能

    1. 监控
    2. 提醒
    3. 自动故障迁移

    基本流程

    • 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
    • 如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 那么这个实例会被 Sentinel 标记为主观下线。
    • 如果一个主服务器被标记为主观下线, 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
    • 如果一个主服务器被标记为主观下线, 并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断, 那么这个主服务器被标记为客观下线。
    • 在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO [section] 命令。 当一个主服务器被 Sentinel 标记为客观下线时, Sentinel 向下线主服务器的所有从服务器发送 INFO [section] 命令的频率会从 10 秒一次改为每秒一次。
    • 当没有足够数量的 Sentinel 同意主服务器已经下线, 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时, 主服务器的主观下线状态就会被移除。

    故障转移

    • 发现主服务器已经进入客观下线状态。
    • 对我们的当前纪元进行自增(详情请参考 Raft leader election ), 并尝试在这个纪元中当选。
    • 如果当选失败, 那么在设定的故障迁移超时时间的两倍之后, 重新尝试当选。 如果当选成功, 那么执行以下步骤。
    • 选出一个从服务器,并将它升级为主服务器。
    • 向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。
    • 通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新。
    • 向已下线主服务器的从服务器发送 SLAVEOF host port 命令, 让它们去复制新的主服务器。
    • 当所有从服务器都已经开始复制新的主服务器时, 领头 Sentinel 终止这次故障迁移操作。

    Sentinel之间和从服务器的自动发现

    • 哨兵之间通过主服务器的__sentinel__:hello频道
    • 从服务器通过询问主服务器获得

    4.集群

    使用集群的好处

    1. 将数据自动切分(split)到多个节点的能力。
    2. 当集群中的一部分节点失效或者无法进行通讯时, 仍然可以继续处理命令请求的能力。

    分片

    所有的key被分配到16384个槽内,分配算法:
    CRC16(key) % 16384
    添加或删除节点时,需要把哈希槽移动到相应的节点

    主从

    支持

    一致性保证

    • 异步复制,不保证数据的强一致性
    • 网络分裂也会导致丢失数据,例如客户端和一个主节点被孤立,集群的其他节点将一个从节点提升为主节点,那么在节点超时时间内客户端的写操作会丢失

    节点超时时间

    对于大多数一方来说, 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群, 那么集群会将这个主节点视为下线, 并使用从节点来代替这个主节点继续工作。
    对于少数一方, 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群, 那么它将停止处理写命令, 并向客户端报告错误。

    故障转移

    主节点之间互相ping,如果没有回复则认为疑似下线并广播,如果半数节点广播了疑似下线,则将他标记为已下线,从节点中选举一个新的主节点

    相关文章

      网友评论

          本文标题:redis 持久化 主从 哨兵 集群等

          本文链接:https://www.haomeiwen.com/subject/tuufmktx.html