开发：读写分离

  • 读写分离：读流量分摊到从节点；且支持 1 主多从节点等
  • 可能遇到的问题：
    • 主从复制延迟（内存性能强，延迟几乎较少）：可通过监控偏移量判定主从延迟是否正常
    • 读取到过期数据：旧版本从机限制写权限导致无法删除过期数据；redis 3.2以上已解决该问题
    • 从节点故障

运维：配置不一致

  • 如：maxmemory 不一致，导致丢失数据
    • 如：主节点配置 4GB；从节点配置 2GB
  • 如：数据结构优化参数（如：hash-max-ziplist-entries）：内存不一致
    • 如：主机节点配置了，从节点没配置

运维：规避全量复制

发生的场景

  • 第一次全量复制：第一次主从配置，不可避免
    • 减少影响的方法：
      • 小主节点（主节点尽量不要太大）
      • 低峰期操作（如夜间）
  • 节点运行 ID 不匹配：如：主节点重启（运行 ID 变化）
    • 减少影响的方法：
      • 故障转移，如：哨兵或集群；即：当主节点挂了后，从节点变更为主节点。
  • 复制积压缓存区不足；
    • 如：网络中断，部分复制无法满足
    • 优化方法：
      • 增大复制积压缓存区配置（rel_backlog_size），默认 1 M；参考配置：10M。
      • 优化网络（多网卡等）

运维：规避复制风暴

含义：即当出现不可预知问题时，恢复的过程，需要进行大量的主从复制恢复操作。

单主节点复制风暴

  • 问题：主节点重启，多从节点复制
    • 即：当主节点挂后，N 台从节点都需要重新 slaveof
  • 优化方法：修改主从复制的拓补图，尽量减少主从之间的影响（附下图：从左优化成右）
    • 该方法并非完美，只是尽量减少。如：slave-1 异常时。

image.png

单机器复制风暴

  • 问题：如下图，当所有 master 节点在同一台机器，当主节点宕机后，复制影响大。
  • 优化方法：
    • 主节点多机器分散部署
    • 高可用架构，如 slave to master

image.png