【基础】redis高可用架构

·  阅读 75

redis如何实现高可用?

持久化、复制、哨兵、集群

  • 持久化:落盘,进程退出不会丢失数据
  • 复制:数据备份
  • 哨兵:故障自动恢复
  • 集群:扩展单机存储能力

1.1 哨兵

sentinel.drawio.png

故障转移流程:

  1. 哨兵sentinel节点定时心跳检测redis节点
  2. redis节点回复超时,主观下线
  3. 主观下线后,询问其他sentinel节点,超过一定数量n后客观下线(redis-master节点才有客观下线和故障转移等,n的值通过配置设置)
  4. sentinel节点选领导者(raft算法)
  5. 故障转移:选主、更新主从状态(修改配置文件等)
  6. 通知switch-master事件订阅者(订阅者感知到switch-master事件后,重新读取sentinel节点sentinel master配置,切换到新的连接) 笔记:
  7. 哨兵节点奇数个,部署到不通物理机(IDC)

扩展:raft协议

1.2 proxy

1. twemproxy

twemproxy.drawio.png

简单分片代理,无法在线扩容、缩容

2. codis集群架构

codis.drawio.png

  1. codis-fe:运维管理后台
  2. codis-dashboard:Codis的集群管理工具,配置中心,整个集群的操作和管理都需要经过dashboard,dashboard中存有集群状态(redis、proxy、slot等状态)
  • 创建zk/etcd/fs客户端
  • 初始化Topom结构体(存储到zk等,包括存储系统配置信息、group、slot、sentinel配置信息等)
  • 清理redis过期连接(每台redis服务器都会有多个连接,过期的连接会被删除)
  • 注册API路由(注册group、slot、sentinel等API操作)
  • 启动4个协程:1、刷新redis状态、主备关系;2、刷新proxy状态;3、同步操作,一个group中主从数据同步;4、处理slot操作
  1. codis-proxy: 启动流程:
  • 创建、填充slot槽 slot:redis-conn
  • jodis在zk中创建临时节点,并监听proxy变化(客户端监听proxy的变化) 接收消息:

codis-proxy.drawio.png

  1. codis-group: 虚拟节点 (redis-master + redis-slave)
  2. storage: 配置存储 zk|etcd|fs
  3. redis-sentinel: 哨兵 codis扩容流程
  4. 新增redis实例并启动(master+slave)
  5. dash-board 增加group
  6. 槽分配,2种方式:auto-rebalance:自动分配1024个槽 | migrage slot:手动分配 流程

codis-mig.drawio.png

同步迁移异步迁移
请求处理针对某个key进行修改,将这个key迁移完成才能处理请求异步则是将当前请求封装成一次SLOTSMGRT-EXEC-WRAPPER调用,并且将操作命令及参数都发送过去,后者会判断这个key是否在迁移或阻塞,如果是并且当前为写命令则直接返回失败,由Proxy重试
迁移逻辑每次随机迁移一个key小key需要确认才算迁移完成,对于大key还会分拆成多条命令,以保证不阻塞主流程,并且在拆分后的命令都加上TTL,以保证如果中途失败目标Redis的key会及时清掉而不会产生脏数据

扩展:zab协议

1.3 cluster

redis-cluster.drawio.png

cluster是redis官方集群方案,节点通信采用gossip协议。 路由:key-槽(16384)-redis节点,双层路由

  1. 优点
  • 去中心架构
  • 自动故障转移
  1. 缺点
  • 客户端相对复杂
  • 最终一致性
  • 不支持读写分离;从库为冷备

扩展:gossip协议

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改