redis高可用汇总（一）

目前redis高可用方案也比较多，本文主要介绍目前主流的redisHA架构

1，主从读写分离

方案描述：

• 本方案是有一个 Master 复制到一个或者多个 Slave 的架构模式，或者级联 slave 架构，通过 Master 对数据库进行写操作，通过 Slave 端进行读操作，该方案主要用在读写压力比较大的应用系统中 , 可以达到读写分离以及负载均衡。

优点：

• 该方案结构灵活，拓展性强，架构搭建简单

缺点：

• 写节点单点故障，主的出现问题需要人工干预，而且其他 slave 都会受到影响，运维困难，没法自动化，二级从节点挂了，影响后面一片

2，twemprocy +redisHA 方案

• 本方案是一个基于第三方插件的 redis 集群，在 rediscluster 出来之前，这种集群解决了单点的问题，为 redis 的大规模应用提供了技术基础。

• 其中 Twemproxy 是 twitter 开源的代理服务 , 在 这里主要的作用是 1. 解决分片的问题 , 这样就不需要客户端自己做分片 , 分片对客户端是透明的 .2. 客户端应用连接 Twemproxy , 主从切换对客户端透明

• Redis sentinel 是 redis 官方提供的 redis 检测工具 , 会检测 redis 的状态然后触发事件 .

• Redis - Twemproxy -Agent 主要是用于监听 redis sentinel 的变更事件 , 修改 Twemproxy 的配置 .

• HAProxy 主要是为了解决 Twemproxy 的高可用问题 。

• 优点

– 解决了分片问题

– 能 保证高 可用，自动化运维，减少人为的干预

• 缺点

– 这个 方案引入的组件过多 , 运维 复杂

– 不支持读写分离 Slave 节点只起备份的 作用

– 运维不友好，甚至没有控制面板

– 无法平滑地扩容 / 缩容（最大的痛点）

– Twemproxy 占用将近 20% 的性能

3，codis集群

• Codis 主要包含 Codis Proxy （ codis -proxy ）、 Codis Manager （ codis-config ）、 Codis Redis （ codis -server ）和 ZooKeeper 四大组件，每个部分都可动态扩容。

• codis -proxy  。 客户端连接的 Redis 代理服务，本身实现了 Redis 协议，表现很像原生的 Redis   （就像  Twemproxy ）。一个业务可以部署多个  codis -proxy ，其本身是无状态的。

• codis-config 。 Codis   的管理工具，支持添加 / 删除 Redis 节点、添加 / 删除 Proxy 节点、发起数据迁移等操作。 codis-config 自带了一个 http server ，会启动一个 dashboard ，用户可以在浏览器上观察  Codis   集群的运行状态。

• codis -server 。 Codis   项目维护的一个 Redis 分支，加入了 slot 的支持和原子的数据迁移指令。

• ZooKeeper 。 Codis 依赖 ZooKeeper 来存放数据路由表和 codis -proxy 节点的元信息， codis-config 发起的命令会通过  ZooKeeper 同步到各个存活的 codis -proxy 。

优点：

• 可扩展性比较强

• 自动化运维；

• 交互式主服务器故障转移 ；

• 无缝迁移 Twemproxy

• 支持 Java 程序的 HA

• 支持 Pipeline

缺点：

• 组件较多，维护复杂，有些出现单点问题

• 由于 Codis 是一个强依赖的 zk 的 项目，对 zk 要求比较高