Redis集群方案调研

摘要: Redis HA方案·概述

1）keepalived：通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失； 
2）Redis代理分片，各大公司推出的redis集群开源方案，直接做成代理服务器，兼容redis和memcached。（为了避代理服务器的单点，也会使用keepalived来做成集群）
3） zookeeper： 通过 ...

Redis HA方案·概述

1）keepalived：通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失；

2）Redis代理分片，各大公司推出的redis集群开源方案，直接做成代理服务器，兼容redis和memcached。（为了避代理服务器的单点，也会使用keepalived来做成集群）
3） zookeeper： 通过 zookeeper 来监控主从实例， 维护最新有效的 IP， 应用通过 zookeeper取得 IP，对 Redis 进行访问，该方案需要编写大量的监控代码；
4）Redis Sentinel：通过 Sentinel 监控主从实例，自动进行故障恢复，该方案有个缺陷：因为主从实例地址是不同的， 当故障发生进行主从切换后， 应用程序无法知道新地址，故 在 Jedis2.2.2 中 新 增 了 对 Sentinel 的 支 持 ， 应 用 通 过redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis实例会及时更新到新的主实 例地址。

5）Redis Cluster

Redis HA方案·具体分析

1）keepalived

基于LVS构建VIP，需要编写大量脚本，运维复杂，常见的主备方案如下引文介绍：

a、【大型网站技术实践】初级篇：借助LVS+Keepalived实现负载均衡

b、主从热备+负载均衡（LVS + keepalived）

2） Redis代理服务器

a、NetFlix对Dynamo的开源通用实现Dynomite

Dynomite是NetFli
3ff0
x对亚马逊分布式存储引擎Dynamo的一个开源通用实现，使用C/C++语言编写、以代理的方式实现的Redis缓存集群方案。Dynomite不仅能够将基于内存的Redis和Memcached打造成分布式数据库，还支持持久化的MySQL、BerkeleyDB、LevelDB等数据库，并具有简单、高效、支持跨数据中心的数据复制等优点。Dynomite的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能。Dynomite遵循Apache License 2.0开源协议发布，更多关于Dynomite的信息请查看NetFlix技术博客对Dynomite的介绍。

b、Twitter的Redis/Memcached代理服务Twemproxy

Twemproxy是一个使用C语言编 写、以代理的方式实现的、轻量级的Redis代理服务器，它通过引入一个代理层，将应用程序后端的多台Redis实例进行统一管理，使应用程序只需要在 Twemproxy上进行操作，而不用关心后面具体有多少个真实的Redis或Memcached实例，从而实现了基于Redis和Memcached的 集群服务。当某个节点宕掉时，Twemproxy可以自动将它从集群中剔除，而当它恢复服务时，Twemproxy也会自动连接。由于是代理，所以 Twemproxy会有微小的性能损失。根据 Redis作者的测试结果，在大多数情况下，Twemproxy的性能相当不错，同直接操作Redis相比，最多只有20%的性能损失。 Twemproxy遵循Apache License 2.0开源协议发布，更多关于Twemproxy的信息请登录其在GitHub的主页查看。

参考文献：

高可用、开源的Redis缓存集群方案

http://www.infoq.com/cn/news/2014/11/open-source-redis-cache

3）zookeeper

豌豆荚的 Redis 集群解决方案Codis

Codis是豌豆荚使用Go和C语言开 发、以代理的方式实现的一个Redis分布式集群解决方案,且完全兼容Twemproxy。Twemproxy对于上一层的应用来说, 连接Codis Proxy（Redis代理服务）和连接原生的Redis服务器没有明显的区别,上一层应用能够像使用单机的 Redis一样对待。Codis底层会处理请求的转发、不停机的数据迁移等工作, 所有底层的一切处理, 对于客户端来说是透明的。总之，可以简单的认为后台连接的是一个内存无限大的Redis服务。Codis遵循MIT开源协议发布，更多关于Codis的信息请登录其在GitHub的主页查看。

提供Java客户端Jodis，支持Pipeline。

需要搭建zookeeper集群。

自动平衡

使用非常简单

图形化的面板和管理工具

支持绝大多数 Redis 命令，完全兼容 twemproxy

支持 Redis 原生客户端

安全而且透明的数据移植，可根据需要轻松添加和删除节点

提供命令行接口

RESTful APIs

参考文献：

高效运维最佳实践（03）：Redis集群技术及Codis实践

http://www.infoq.com/cn/articles/effective-ops-part-03

安装与介绍

http://www.oschina.net/p/codis

http://www.oschina.net/news/71823/codis-3-0-3-2-0-14

4）Redis Sentinel

版本要求：Redis 2.8，其Sentinel版本称为Sentinel 2，是在Sentinel 1的基础上重写的。因为Sentinel 1已经废弃而且BUG太多，所以强烈建议将Redis和Sentinel均升级到2.8版本。

Sentinel&Jedis看上去是个完美的解决方案，这句话只说对了一半，在无分片的情况是这样，但我们的应用使用了数据分片 -sharing，每个实例以主从结构部署，Jedis没有提供基于Sentinel的 ShardedJedisPool，那么就要参照第三方的实现了，引入基于Sentinel的ShardedJedisPool，使用客户端分片：

http://www.tuicool.com/articles/naeEJbv

参考文献：

sentinel、JedisSentinelPool实战

http://lanjingling.github.io/2015/12/29/redis-sentinel-jedis-shizhan/

原理简析：

http://doc.redisfans.com/topic/sentinel.html

http://www.bubuko.com/infodetail-926782.html

http://www.redis.cn/topics/sentinel.html

5）Redis Cluster

已使用官方版本：3.0.7

最新稳定版已经发布到3.2：http://redis.io/download

客户端使用jedis2.8.1，完美支持

参考阅读：

Redis集群介绍与规范：

http://doc.redisfans.com/topic/cluster-tutorial.html#id2

http://doc.redisfans.com/topic/cluster-spec.html

http://ifeve.com/redis-cluster-spec/

安装详解：

http://blog.csdn.net/xu470438000/article/details/42971091

动态运维：

http://blog.csdn.net/xu470438000/article/details/42972123

附，推荐阅读：

Redis 命令参考

http://doc.redisfans.com/

Redis中文网

http://www.redis.net.cn/tutorial/3501.html

Redis集群方案应该怎么做？

https://www.zhihu.com/question/21419897