Redis集群方案（来自网络）

参考：

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

http://www.cnblogs.com/haoxinyue/p/redis.html

 

为什么集群？

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2.Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

1. 采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

   2.为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

   3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

   
   
   

   Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。

   当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。

   作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？

   Redis作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。

   presharding是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。并不是只有增删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。

   这样，我们的架构模式变成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成： Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。

    

   高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。

   可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。

    

   3.利用代理中间件实现大规模Redis集群

   上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。

   客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：

2. 由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。
3. 服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。
4. 连接不能共享，当应用规模增大时，资源浪费制约优化。

   服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。

   不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

   能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。

   twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。

   参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：

   twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。

   twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

   twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。

   由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。

   当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。

    

    

   基于Twemproxy的Redis集群方案

    

   概述

   由于单台redis服务器的内存管理能力有限，使用过大内存redis服务器的性能急剧下降，且服务器发生故障将直接影响大面积业务。为了获取更好的缓存性能及扩展型，我们将需要搭建redis集群来满足需求。因redis 3.0 beta支持的集群功能不适合生产环境的使用，所以我们采用twitter正在使用的twemproxy来搭建redis缓存服务器集群，目前用户包括Pinterest、Tumblr、Twitter、Vine、Kiip、Wuaki.tv、Wanelo、Kontera、Wikimedia、Bright、56.com、Snapchat、Digg、Gawkermedia、3scale.net等。

   Twemproxy是memcached和redis协议的代理服务器，并能有效减少大量连接对redis服务器的性能影响，它提供的主要特性如下:

   

      

      

   集群架构

   

      

   安装Redis

   有三台服务器，一台COS1安装twemproxy，另外两台COS2，COS3安装redis。

      

   1. 下载最新安装包：redis-2.8.9.tar.gz ， tcl-8.5.7-6.el6.x86_64.rpm ，nutcracker-0.3.0.tar.gz
   2. 
   3. 安装必要组件rpm：

   4. [root@COS2 redis-2.8.9]# yum install gcc

      [root@COS2 src]# rpm -ivh tcl-8.5.7-6.el6.x86_64.rpm

   5. 安装Redis：

      

      [root@COS2 src]# tar xvf redis-2.8.9.tar.gz

      [root@COS2 src]# cd redis-2.8.9

      [root@COS2 redis-2.8.9]# make

      …
      

      Hint: To run 'make test' is a good idea ;)
      

      make[1]: Leaving directory `/usr/local/src/redis-2.8.9/src'
      

       

      [root@COS2 redis-2.8.9]# make test

      All tests passed without errors!
      

       

      Cleanup: may take some time... OK
      

      make[1]: Leaving directory `/usr/local/src/redis-2.8.9/src'
      

      [root@COS2 redis-2.8.9]# make install

      [root@COS2 redis-2.8.9]# cd /usr/local/bin/

      [root@COS2 bin]# ll

      total 13908
      

      -rwxr-xr-x. 1 root root 4170264 Apr 26 11:51 redis-benchmark
      

      -rwxr-xr-x. 1 root root   22185 Apr 26 11:51 redis-check-aof
      

      -rwxr-xr-x. 1 root root   45419 Apr 26 11:51 redis-check-dump
      

      -rwxr-xr-x. 1 root root 4263471 Apr 26 11:51 redis-cli
      

      -rwxr-xr-x. 1 root root 5726791 Apr 26 11:51 redis-server
      

      

   6. 编辑redis配置文件：

      

      [root@COS2 redis-2.8.9]# cp redis.conf /etc/

      [root@COS2 redis-2.8.9]# vim /etc/red

      redhat-release  redis.conf      
      

      [root@COS2 redis-2.8.9]# vim /etc/redis.conf

       

      把里面的
      

      daemonize no  修改成 daemonize yes
      

      

   7. 启动redis服务：

      [root@COS2 redis-2.8.9]# redis-server /etc/redis.conf

   8. 测试redis服务：

   9. [root@COS2 redis-2.8.9]# redis-cli 

   10. 127.0.0.1:6379> set kin kin
       

   11. OK
       

       127.0.0.1:6379> get kin
       

   12. 同样的步骤安装其他redis服务器。

      

      

   安装twemproxy

   1. 安装twemproxy：

   2. [root@COS1 src]# tar xvf nutcracker-0.3.0.tar.gz

   3. [root@COS1 nutcracker-0.3.0]# cd nutcracker-0.3.0

   4. [root@COS1 src]#./configure 

      [root@COS1 nutcracker-0.3.0]# make && make install

   5. 编辑配置文件：

      

      [root@COS1 conf]# cd /usr/local/src/nutcracker-0.3.0/conf

      [root@COS1 conf]# cp nutcracker.yml /etc/

      [root@COS1 conf]# vim /etc/nutcracker.yml

      alpha:
      

        listen: 0.0.0.0:22121
      

        hash: fnv1a_64
      

        distribution: ketama
      

        auto_eject_hosts: true

        redis: true

        server_retry_timeout: 2000
      

        server_failure_limit: 1
      

        servers: --两台redis服务器的地址和端口
      

         - 10.23.22.240:6379:1   
      

         - 10.23.22.241:6379:1
      

      

   6. 测试配置文件：

   7. [root@COS1 nutcracker-0.3.0]# nutcracker -t /etc/nutcracker.yml 

      nutcracker: configuration file 'conf/nutcracker.yml' syntax is ok
      

   8. 启动twemproxy：

      

      [root@COS1 nutcracker-0.3.0]# nutcracker  --help

      This is nutcracker-0.3.0
      

       

      Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
      

                        [-c conf file] [-s stats port] [-a stats addr]
      

                        [-i stats interval] [-p pid file] [-m mbuf size]
      

       

      Options:
      

        -h, --help             : this help                           
      

        -V, --version          : show version and exit                 
      

        -t, --test-conf        : test configuration for syntax errors and exit 
      

        -d, --daemonize      : run as a daemon                    
      

        -D, --describe-stats   : print stats description and exit
      

        -v, --verbosity=N      : set logging level (default: 5, min: 0, max: 11)
      

        -o, --output=S         : set logging file (default: stderr)
      

        -c, --conf-file=S      : set configuration file (default: conf/nutcracker.yml) #配置

        -s, --stats-port=N     : set stats monitoring port (default: 22222)
      

        -a, --stats-addr=S     : set stats monitoring ip (default: 0.0.0.0)
      

        -i, --stats-interval=N : set stats aggregation interval in msec (default: 30000 msec)
      

        -p, --pid-file=S       : set pid file (default: off)
      

        -m, --mbuf-size=N      : set size of mbuf chunk in bytes (default: 16384 bytes)
      

      [root@COS1 nutcracker-0.3.0]# nutcracker -d -c /etc/nutcracker.yml

      [root@COS1 nutcracker-0.3.0]# ps -ef|grep nutcracker

      root     15358     1  0 02:40 ?        00:00:00 nutcracker -d -c /etc/nutcracker.yml
      

      

   9. 测试twemproxy：

      

      [root@COS1 ~]# redis-cli -p 22121

      127.0.0.1:22121> get kin
      

      "kin"

      127.0.0.1:22121> set kin king
      

      OK
      

      127.0.0.1:22121> get kin
      

      "king"

      

      

      

      

      

   性能测试

   这里使用redis自带的redis-benchmark进行简单的性能测试，测试结果如下:

   1. Set测试：
      1. 通过twemproxy测试：

         [root@COS1 src]# redis-benchmark -h 10.23.22.240 -p 22121 -c 100 -t set -d 100 -l –q

         SET: 38167.94 requests per second
         

      2. 直接对后端redis测试：

         [root@COS2 ~]# redis-benchmark -h 10.23.22.241 -p 6379 -c 100 -t set -d 100 -l –q

         SET: 53191.49 requests per second
         

   2. Get测试：
      1. 通过twemproxy测试：

      2. [root@COS1 src]# redis-benchmark -h 10.23.22.240 -p 22121 -c 100 -t get -d 100 -l -q

         GET: 37453.18 requests per second
         

      3. 直接对后端redis测试：

      4. [root@COS2 ~]# redis-benchmark -h 10.23.22.241 -p 6379 -c 100 -t get -d 100 -l -q

         GET: 62111.80 requests per second
         

   3. 查看键值分布：

   4. [root@COS2 ~]# redis-cli info|grep db0

   5. db0:keys=51483,expires=0,avg_ttl=0
      

   6.  

   7. [root@COS3 ~]# redis-cli info|grep db0

      db0:keys=48525,expires=0,avg_ttl=0
      

   测试结果:以基本的set get命令通过twemproxy性能有所下降;通过twemproxy分布基本平均。测试数据以业务测试为准。

   Redis 代理服务Twemproxy

   1、twemproxy explore

         当我们有大量 Redis 或 Memcached 的时候，通常只能通过客户端的一些数据分配算法（比如一致性哈希），来实现集群存储的特性。虽然Redis 2.6版本已经发布Redis Cluster，但还不是很成熟适用正式生产环境。 Redis 的 Cluster 方案还没有正式推出之前，我们通过 Proxy 的方式来实现集群存储。

          Twitter，世界最大的Redis集群之一部署在Twitter用于为用户提供时间轴数据。Twitter Open Source部门提供了Twemproxy。

        Twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器，非常具有应用价值。但是当使用比较多的时候，就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。

         Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：

        它全部用C写成，使用Apache 2.0 License授权。项目在Linux上可以工作，而在OSX上无法编译，因为它依赖了epoll API.

         Twemproxy 通过引入一个代理层，可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配，使应用程序只需要在 Twemproxy 上进行操作，而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。 

   2、twemproxy特性：

• 支持失败节点自动删除
  • 可以设置重新连接该节点的时间
  • 可以设置连接多少次之后删除该节点
  • 该方式适合作为cache存储
• 支持设置HashTag
  • 通过HashTag可以自己设定将两个KEYhash到同一个实例上去。
• 减少与redis的直接连接数
  • 保持与redis的长连接
  • 可设置代理与后台每个redis连接的数目
• 自动分片到后端多个redis实例上
  • 多种hash算法：能够使用不同的策略和散列函数支持一致性hash。
  • 可以设置后端实例的权重
• 避免单点问题
  • 可以平行部署多个代理层.client自动选择可用的一个
• 支持redis pipelining request

     支持请求的流式与批处理，降低来回的消耗 

• 支持状态监控
  • 可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
  • 可设置监控信息刷新间隔时间
• 高吞吐量
  • 连接复用，内存复用。
  • 将多个连接请求，组成reids pipelining统一向redis请求。

     另外可以修改redis的源代码，抽取出redis中的前半部分，作为一个中间代理层。最终都是通过linux下的epoll 事件机制提高并发效率，其中nutcraker本身也是使用epoll的事件机制。并且在性能测试上的表现非常出色。

3、twemproxy问题与不足

Twemproxy 由于其自身原理限制，有一些不足之处，如：  

• 不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外）
• 不支持Redis的事务操作
• 出错提示还不够完善
• 也不支持select操作

4、安装与配置 

具体的安装步骤可用查看github： https://github.com/twitter/twemproxy

Twemproxy 的安装，主要命令如下： 

apt-get install automake

apt-get install libtool

git clone git://github.com/twitter/twemproxy.git

cd twemproxy

autoreconf -fvi

./configure --enable-debug=log

make

src/nutcracker -h

通过上面的命令就算安装好了，然后是具体的配置，下面是一个典型的配置 

redis1:

listen: 127.0.0.1:6379 #使用哪个端口启动Twemproxy

redis: true #是否是Redis的proxy

hash: fnv1a_64 #指定具体的hash函数

distribution: ketama #具体的hash算法

auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点

timeout: 400 #超时时间（毫秒）

server_retry_timeout: 2000 #重试的时间（毫秒）

server_failure_limit: 1 #结点故障多少次就算摘除掉

servers: #下面表示所有的Redis节点（IP:端口号:权重）

- 127.0.0.1:6380:1

- 127.0.0.1:6381:1

- 127.0.0.1:6382:1

redis2:

listen: 0.0.0.0:10000

redis: true

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: false

timeout: 400

servers:

- 127.0.0.1:6379:1

- 127.0.0.1:6380:1

- 127.0.0.1:6381:1

- 127.0.0.1:6382:1

你可以同时开启多个 Twemproxy 实例，它们都可以进行读写，这样你的应用程序就可以完全避免所谓的单点故障。  

 

Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失（twitter测试约20%），但是能够提高整个系统的HA也是相当划算的。不熟悉twemproxy的同学，如果玩过nginx反向代理或者mysql proxy，那么你肯定也懂twemproxy了。其实twemproxy不光实现了redis协议，还实现了memcached协议，什么意思？换句话说，twemproxy不光可以代理redis，还可以代理memcached

 

twemproxy不会增加redis的性能指标数据，据业界测算，使用twemproxy相比直接使用redis会带来~10%的性能下降。

   

但是单个redis进程的内存管理能力有限。据测算，单个redis进程内存超过20G之后，效率会急剧下降。目前，我们给出的建议值是单个redis最好配置在8G以内。8G以上的redis缓存需求，通过twemproxy来提供支持。

 

Twemproxy的强大之处在于可以通过配置的方式让它禁用掉失败的结点，同时还能在一段时间后进行重试，抑或使用指定的键->服务器映射。这意味着在将Redis用作数据存储时，它可以对Redis数据集进行分片（禁用掉结点驱逐）；在将Redis用作缓存时，它可以启用结点驱逐以实现简单的高可用性。

 

TwemProxy支持自动分片、失败节点摘除、一致性hash，优化Redis请求(批处理)等，同时TwemProxy也有一些不足之处，例如无法全面覆盖Redis命令(不支持事务，多值操作(如keys*))。扩展Redis实例时，无法自动将之前数据进行再分配(需要写脚本手动分配)。