荔枝Redis高可用方案

一、背景

• 线上redis架构，总共大概250套主从
• 架构以1主1从为主，少部分1主多从
• 大部分主库抗业务，从库做持久化及定时备份
• 少部分主从（大概30多套）通过应用配置读写域名实现读写分离

二、关于目前Redis读写分离方案的一些看法

1. 目前线上的读写分离是否有必要（单实例扛不住的原因在哪里）
2. 从库做持久化对请求的影响（需要额外挂从库做持久化）

3. 如果真的需要做读写分离，应该怎么做

   
   
   

   image.png

image.png

结论：大部分业务没必要做读写分离。读写分离适合读多写少场景，并且至少部署2个从做负载均衡分摊读负载。而rdb持久化/aof重写等操作会阻塞业务库，所以有备份需求的架构需要额外添加一个从库用于持久化备份。复杂的架构也不利于高可用的设计。根据实际业务场景将数据拆分可能会是更好的选择。

三、业界成熟Redis高可用架构介绍

1. sentinel

sentinel架构

sentinel 检测原理

• 每隔10s，每个sentinel会向主节点和从节点发送info replication命令获取最新的主从拓扑结构
• 每隔2s，每个sentinel节点向redis节点的__ sentinel __:hello频道发送该sentinel节点对主节点判断及当前sentinel信息，其他sentinel节点也会订阅该频道，了解各个sentinel节点以及他们对主节点的判断
• 每隔1s，每个sentinel节点会向所有redis节点以及其他sentinel节点发送ping命令做一次心跳检测，确认各个节点是否可达

sentinel 切换原理

主观下线：sentinel节点通过每2秒的ping心跳检测，超过down-after-milliseconds主观判断redis节点下线

客观下线：sentinel节点判断主观下线后，通过发送sentinel ismaster-down-by-addr到其他sentinel节点询问对主节点的判断，当超过quonum个数，则判断该redis主节点客观下线

故障转移过程

1. sentinel节点判断redis节点主观下线
2. sentinel节点判断redis节点客观下线
3. sentinel节点发起选举，一旦节点获得max(quorum,num(sentinels)/2+1)的票数，即成为leader（选举过程非常快，基本上谁先完成客观下线，谁就是leader）
4. 由sentinel leader节点进行redis failover

redis failover 包括提升redis从库为主库，将其他从库挂载到新主库等操作

特点

• 一套sentinel集群至少3个节点，sentinel节点通过raft算法选举，节点个数为奇数
• 1套sentinel集群可以监控多套redis主从
• 建议部署方式：相同业务使用同一套sentinel集群进行监控。
• Client 端需要修改连接方式，配置由原来直连域名，修改为配置sentinel集群信息+redis主节点标识名
• sentinel只对主节点进行failover，从节点故障只做主观下线判断，没有后续的处理操作
• sentinel不是中间件，应用只会在初次连接的时候请求sentinel返回一个redis主节点的连接池，实际上是直连redis主节点的。（持续订阅sentinel，当redis发生故障切换，会重新返回一个主节点连接池）

痛点

• 客户端原生JedisSentinelPool只拿到redis主节点的连接池，无法支持读写分离
• 应用端需要修改连接配置（这个其实不算很痛，可以逐步推进）

2. Redis-Cluster

redis-cluster

特点

• 无中心分布式架构，解决高可用，扩展性问题
• 集群中数据节点个数为奇数。每个节点代表一套redis主从（主库读写，从库备用）
• 通过虚拟槽hash到各节点（总共16384个slots），实现数据分片
• 无代理层，client端配置集群所有节点信息。连接集群中任一节点皆可访问整个集群数据（自动路由）
• 据说存在不少坑，需要先部署测试一段时间再上线
  
  

四、适合荔枝的Redis高可用架构

从荔枝整体redis环境看，redis多为单主从，实例数据大部分在10G以内，不同业务之间实例相互独立。sentinel是最合适的高可用方式。主要解决读写分离和域名切换的问题，这里给出2种方案

1. sentinel+consul

sentinel 负责故障主从切换，consul 主要提供DNS，健康检测，服务发现，域名切换
consul简介

consul introduce

整体架构

consul+sentinel redis高可用

说明

• 客户端需要改成特定后缀的域名格式（比如.consul）
• 每台缓存机器部署一个consul client，用于该机器所有redis实例的服务发现，健康检测
• consul可以实现从节点的故障转移
  
  

2. sentinel（取消读写分离） + redis-cluster（个别大数据量高并发实例）

整体架构

redis+sentinel架构图.png

说明

• 这套架构可以满足目前90%的redis高可用需求，架构复杂度低，建议优先考虑
• python redis库支持读写分离，可以通过master标识名拿到从库连接。jedis待测试

    >>> from redis.sentinel import Sentinel
    >>> sentinel = Sentinel([('localhost', 26379)], socket_timeout=0.1)
    >>> master = sentinel.master_for('mymaster', socket_timeout=0.1)
    >>> master.set('foo', 'bar')
    >>> slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
    >>> slave.get('foo')

• 对于现有的小部分做了读写分离的实例，先评估是否可以取消掉读写分离，接入sentinel
• 对于大数据量，高并发的实例，考虑接入Redis-Cluster
  
  

3. sentinel + jedis改造（支持从库failover）

说明

• 原生sentinel实现master failover
• 对于从库故障sentinel 只做主观下线判断（ +sdown）不进行failover
• 通过这个特点，可以通过改造客户端，将所有从节点看做一个资源池。订阅sentinel和从节点变动有关的事件消息，从而动态返回从节点连接池
• 这套方案架构简单，并能支持读写分离以及主从库故障转移，是目前我们选择的高可用方案

从库变动相关的事件

·+switch-master：切换主节点（原来的从节点晋升为主节点），说明减
少了某个从节点。
·+convert-to-slave：切换从节点（原来的主节点降级为从节点），说明
添加了某个从节点。
·+sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点
不会做客观下线），所以在实现客户端时可以采用自身策略来实现类似主观
下线的功能。
·+reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加
了某个从节点。