关于redis集群的一些事

 

一:关于redis cluster

1:   redis cluster的现状

reids-cluster计划在redis3.0中推出，可以看作者antirez的声明:http://antirez.com/news/49 (ps:跳票了好久，今年貌似加快速度了),目前的最新版本见:https://raw.githubusercontent.com/antirez/redis/3.0/00-RELEASENOTES 

目前redis支持的cluster特性(已测试):

1):节点自动发现

2):slave->master 选举,集群容错

3):Hot resharding:在线分片

4):集群管理:cluster xxx

5):基于配置(nodes-port.conf)的集群管理

6):ASK 转向/MOVED 转向机制.

2:   redis cluster 架构

1)redis-cluster架构图

 


架构细节:

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

2) redis-cluster选举:容错

 


(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉.

(2):什么时候整个集群不可用(cluster_state:fail)? 

    a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完成时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.

    b:如果集群超过半数以上master挂掉，无论是否有slave集群进入fail状态.

  ps:当集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误

－－－－

--------------------------------------------------------

如果上面看不下去，看下下面的小结也可以：

---------------------------------------------------------

小结：

通过上面一些补充的介绍我们看到，redis－cluster之所以跳票也是可以理解的，

他做的功能十分“强大”，虽然目前给人感觉不是很实用的感觉。

为啥呢？

 因为访问其他Redis3.0服务器的Key需要二次定位，这就是Redis3.0所谓的 ASK
转向/MOVED 转向机制 

 Redis最初的使命是用高效的内存取代复杂繁重的数据库，如果从缓存服务器获取一个Key要经过二次定位，

访问时间是原来单机缓存服务器的两倍，那样我们还是直接用数据库好了。

 

     鉴于Redis3.0所谓的ASK 转向/MOVED 转向机制，

     网上推出了JAVA版的Redis3.0客户端库jedis、C++版的Redis3.0客户端库ACL，

他们都支持根据Redis服务器居返回"MOVED"信息进行二次定位数据访问，而且还有在主备切换的情况下访问备机的功能，

正常情况下Redis3.0集群要部署3台主机和3台备机，这样客户端就要同时维持这6台服务器的长连接，像有些系统有上百个

进程，一个线程就要维持6台缓存服务器的长连接，一个进程拥有多个线程，总的算起来差不多上千个缓存服务器的长连接，

这无异于饮鸩止渴。

         最理想的方案就是Redis3.0 Cluster加入集群代理功能，实现客户端通过任何一台缓存服务器一次性定位所有的Key，当然这要等

待antirez发力，短期看似乎不大可能；客户端优化方案就是加入计算Key的哈希槽值的逻辑，加载服务器端的哈希槽存储逻辑，

来实现一次性定位访问缓存服务器，这样做的缺陷还是避免不了多台缓存服务器的长连接，同时一旦缓存服务器发生数据迁移和主

备切换的情况，客户端就得变更哈希槽存储逻辑。

那么作者为何要让redis去实现这样的功能呢？那得问作者本人了。

 

－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－－－

                                      看完上面的铺垫，应该就明白，为何下面要推荐一个叫codis的代理了。

－－－－－－－－－－－－－－－－－－－

本文重点推荐Codis——豌豆荚开源的Redis分布式中间件（该项目于4个月前在GitHub开源，目前star已超过2100）。其和Twemproxy相比，有诸多激动人心的新特性，并支持从Twemproxy无缝迁移至Codis。

本文主要目录如下，对Redis比较了解的朋友，可跳过前两部分，直接欣赏Codis相关内容。

1. Redis常见集群技术

   1.1 客户端分片

   1.2 代理分片

   1.3 Redis Cluster

2. Twemproxy及不足之处

3. Codis实践

   3.1 体系架构

   3.2 性能对比测试

   3.3 使用技巧、注意事项

好吧我们正式开始。

1. Redis常见集群技术

长期以来，Redis本身仅支持单实例，内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低——毕竟现在服务器内存动辄100~200GB。

为解决单机承载能力不足的问题，各大互联网企业纷纷出手，“自助式”地实现了集群机制。在这些非官方集群解决方案中，物理上把数据“分片”（sharding）存储在多个Redis实例，一般情况下，每一“片”是一个Redis实例。

包括官方近期推出的Redis Cluster，Redis集群有三种实现机制，分别介绍如下，希望对大家选型有所帮助。

1.1 客户端分片

这种方案将分片工作放在业务程序端，程序代码根据预先设置的路由规则，直接对多个Redis实例进行分布式访问。这样的好处是，不依赖于第三方分布式中间件，实现方法和代码都自己掌控，可随时调整，不用担心踩到坑。

这实际上是一种静态分片技术。Redis实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。

这种分片机制的性能比代理式更好（少了一个中间分发环节）。但缺点是升级麻烦，对研发人员的个人依赖性强——需要有较强的程序开发能力做后盾。如果主力程序员离职，可能新的负责人，会选择重写一遍。

所以，这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。

这种方案，难以进行标准化运维，不太适合中小公司（除非有足够的DevOPS）。

1.2 代理分片

这种方案，将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。



这种机制下，一般会选用第三方代理程序（而不是自己研发），因为后端有多个Redis实例，所以这类程序又称为分布式中间件。这样的好处是，业务程序不用关心后端Redis实例，运维起来也方便。虽然会因此带来些性能损耗，但对于Redis这种内存读写型应用，相对而言是能容忍的。这是我们推荐的集群实现方案。像基于该机制的开源产品Twemproxy，便是其中代表之一，应用非常广泛。

1.3 Redis Cluster

在这种机制下，没有中心节点（和代理模式的重要不同之处）。所以，一切开心和不开心的事情，都将基于此而展开。

Redis Cluster将所有Key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。

Redis Cluster的成员管理（节点名称、IP、端口、状态、角色）等，都通过节点之间两两通讯，定期交换并更新。

由此可见，这是一种非常“重”的方案。已经不是Redis单实例的“简单、可依赖”了。可能这也是延期多年之后，才近期发布的原因之一。

这令人想起一段历史。因为Memcache不支持持久化，所以有人写了一个Membase，后来改名叫Couchbase，说是支持Auto Rebalance，好几年了，至今都没多少家公司在使用。

这是个令人忧心忡忡的方案。为解决仲裁等集群管理的问题，Oracle RAC还会使用存储设备的一块空间。而Redis Cluster，是一种完全的去中心化……

本方案目前不推荐使用，从了解的情况来看，线上业务的实际应用也并不多见。（重要内容红色加粗）

2. Twemproxy及不足之处

Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。

这个方案顺理成章地解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。

我想很多人都应该感谢Twemproxy，这么些年来，应用范围最广、稳定性最高、最久经考验的分布式中间件，应该就是它了。只是，他还有诸多不方便之处。

Twemproxy最大的痛点在于，无法平滑地扩容/缩容。

这样导致运维同学非常痛苦：业务量突增，需增加Redis服务器；业务量萎缩，需要减少Redis服务器。但对Twemproxy而言，基本上都很难操作（那是一种锥心的、纠结的痛……）。

或者说，Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。

Twemproxy另一个痛点是，运维不友好，甚至没有控制面板。

Codis刚好击中Twemproxy的这两大痛点，并且提供诸多其他令人激赏的特性。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

3. Codis实践

主角登场，给个超大字体

Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。现已广泛用于豌豆荚的各种Redis业务场景（已得到豌豆荚@刘奇－－豌豆荚架构师的确认，呵呵）。

从3个月的各种压力测试来看，稳定性符合高效运维的要求。性能更是改善很多，最初比Twemproxy慢20%；现在比Twemproxy快近100%（条件：多实例，一般Value长度）。

3.1 体系架构

Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。

为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。

Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。



ZooKeeper还维护Codis Server Group信息，并提供分布式锁等服务。

3.2 性能对比测试

Codis目前仍被精益求精地改进中。其性能，从最初的比Twemproxy慢20%（虽然这对于内存型应用而言，并不明显），到现在远远超过Twemproxy性能（一定条件下）。

我们进行了长达3个月的测试。测试基于redis-benchmark，分别针对Codis和Twemproxy，测试Value长度从16B~10MB时的性能和稳定性，并进行多轮测试。

一共有4台物理服务器参与测试，其中一台分别部署codis和twemproxy，另外三台分别部署codis server和redis server，以形成两个集群。

从测试结果来看，就Set操作而言，在Value长度<888B时，Codis性能优越优于Twemproxy（这在一般业务的Value长度范围之内）。



就Get操作而言，Codis性能一直优于Twemproxy。

3.3 使用技巧、注意事项

Codis还有很多好玩的东东，从实际使用来看，有些地方也值得注意。

1）无缝迁移Twemproxy

出品方贴心地准备了Codis-port工具。通过它，可以实时地同步 Twemproxy 底下的 Redis 数据到你的 Codis 集群。同步完成后，只需修改一下程序配置文件，将 Twemproxy 的地址改成 Codis 的地址即可。是的，只需要做这么多。

2）支持Java程序的HA

Codis提供一个Java客户端，并称之为Jodis（名字很酷，是吧？）。这样，如果单个Codis Proxy宕掉，Jodis自动发现，并自动规避之，使得业务不受影响（真的很酷！）。

3）支持Pipeline

Pipeline使得客户端可以发出一批请求，并一次性获得这批请求的返回结果。这提升了Codis的想象空间。

从实际测试来看，在Value长度小于888B字节时，Set性能迅猛提升；



Get性能亦复如是。

4）Codis不负责主从同步

也就是说， Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。

这是我最赞赏的地方之一。这样的好处是，没把Codis搞得那么重。也是我们敢于放手在线上环境中上线的原因之一。

5）对Codis的后续期待？

好吧，粗浅地说两个。希望Codis不要变得太重。另外，加pipeline参数后，Value长度如果较大，性能反而比Twemproxy要低一些，希望能有改善（我们多轮压测结果都如此）。

因篇幅有限，源码分析不在此展开。另外Codis源码、体系结构及FAQ，参见如下链接：https://github.com/wandoulabs/codis

PS：线上文档的可读性，也是相当值得称赞的地方。一句话：很走心，赞！

最后，Redis初学者请参考这个链接：http://www.gamecbg.com/bc/db/redis/13852.html，文字浅显易懂，而且比较全面。

－－－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－－

如果想动手试下

教程参考地址：
https://github.com/wandoulabs/codis/blob/master/doc/tutorial_zh.md http://blog.csdn.net/freewebsys/article/details/44100919
－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－

参考文章：

http://www.infoq.com/cn/articles/effective-ops-part-03?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_news_clk

http://hot66hot.iteye.com/blog/2050676

http://www.cnblogs.com/guoyinglin/p/4604279.html