Redis集群方案理解及实践

一.总述

redis集群实现有两种方式，一种是在服务器端做集群，另一种是在客户端做集群。

• 客户端集群
  
  • 好处在于各个redis节点之间相互独立，不需要考虑和其他节点的关联。
  • 弊端则在于使用方需要知道并配置集群中所有的节点IP。当集群发生节点增加或减少时，应用方必须相应地修改配置文件。
• 服务器端集群
  
  • 服务器端做集群优缺点和客户端就正好相反。
  • 好处是对使用方来说更简单，只需要集群接入的服务器IP地址即可，就相当于用一个redis实例。后面请求具体分发到哪一个节点上，由集群来进行分配，客户端不用关心。
  • 不好的地方则是需要考虑分布式集群的各个细节，各个redis之间的关系，等等，搭建起来会比较费劲一点。

下面详细地讲一下这两种集群方案的实现方式。

二.客户端集群

在客户端做集群，主要的思路就是对key进行hash，然后利用hash值计算出该key应该映射到哪台redis上。

2.1hash%N

最简单的就是利用hash%N的公式。这样能够均衡地将key分配到各个redis节点上。

但是此种方法有个非常大的弊端，在扩容或者删减节点时，将会导致所有的缓存失效—-所有的key都不能映射到其原本存储的节点。这样将导致所有的缓存值都将重新从DB取出，会给后端DB带来很大压力。

因此更科学地做法需要做到节点删除之后，仅需要迁移之前存到这个节点上的缓存，而其他节点上的数据不会发生迁移。

2.2一致性hash

一致性hash算法即是满足这样条件的一种算法思想，用来计算key到节点之间的映射关系。

一致性hash算法主要有以下几个特性：

• 一致性：在集群中增加节点的时候，原来的集群中所有的缓存，要么不迁移，要么迁移到新的节点上去，不会迁移到集群中旧的节点上去。或者说集群不变时，一个缓存永远都打在同一个节点上，集群节点增加，他可能打在新增加的节点上。
• 均衡性：要尽量保证所有的key能够平均地打到每一个节点上。这样可以平衡各个节点的负载，redis的存储占用也更均匀。
• 分散性：对同一份缓存，只会在某一个节点上保存，不会保存在多个节点上。

它的主要实现思路如下：

1. 先将所有的hash值结果看成一个环。
2. 比如一般的hash值的范围是int，那么这个环的值范围也就是int。
3. 然后计算出所有的redis节点（IP、IP+name等）的hash值，将其映射到这个圆环上，找到节点对应的圆环上的点。
4. 接着在某个key进来的时候，用同样的hash算法计算出该key的hash值，按照特定的方向（如顺时针）开始寻找redis节点在上面的点，遇到的第一个redis节点即作为当前key的映射节点。

这样说可能有点不容易理解。有困惑的朋友可以看看下面这篇文章，里面有这个算法的图解，看起来更加直观易懂。
一致性hash原理图示

经过这样的处理之后，一个redis节点对应圆环上的一块区域，key也对应着圆环上的一个点。所以在新增节点或者删除节点之后，只是圆环上相应区域内的key会发生迁移，而其他的key依然映射在之前的点。这样就满足了一致性这个特性。

要想满足均衡性，就必须得让每个节点均衡地分布在圆环上。但是对于节点比较少的情况来说，很难做到对这些节点计算出来的hash值刚好平分这个圆环的范围。

因此我们可以对这N个节点建立M个虚拟节点副本的方式来解决这个问题。在上面第3步计算节点对应的圆环位置时，可以用hash（IP + i）的方式计算。这样在整个圆环上，就会比较均衡地分布着各个虚拟节点，因此真实节点的均衡性也就得到了保证。（可以想到副本数量越大，均衡性会越好）

这里是我一个一致性hash算法的Java版本的实现，有兴趣的可以看看。
一致性hash算法Java实现

2.3Jedis Sharding

对于Java开发来说，Jedis里面已经实现了这种一致性hash算法，因此实际开发中就不需要我们再去自己实现了。

下面给出一个Jedis Sharding的用法示例：

public static void main(String[] args) {
        //连接池配置设置
        GenericObjectPoolConfig gpoolConfig = new GenericObjectPoolConfig();
        gpoolConfig.setMaxTotal(200);
        gpoolConfig.setMaxIdle(10);
        gpoolConfig.setMaxWaitMillis(1000);

        //redis集群节点信息配置
        List<JedisShardInfo> shards = Lists.newArrayList();
        JedisShardInfo info1 = new JedisShardInfo("192.168.99.233", 6379, 1000, 1);
        JedisShardInfo info2 = new JedisShardInfo("192.168.98.250", 6379, 1000, 1);
        JedisShardInfo info3 = new JedisShardInfo("192.168.96.48", 6380, 1000, 1);
        shards.add(info1);shards.add(info2);shards.add(info3);

        //创建sharding pool
        ShardedJedisPool shardedJedisPool = new ShardedJedisPool(gpoolConfig, shards);

        /**
         * 测试代码
         */
        int num1 = 0;
        int num2 = 0;
        int num3 = 0;

        for(int i = 0; i < 1000; i++) {
            String key = "nova_" + i;
            ShardedJedis shardedJedis = null;
            try{
                shardedJedis = shardedJedisPool.getResource();
            }catch(Exception e) {
                e.printStackTrace();
                if(shardedJedis != null) {
                    shardedJedisPool.returnBrokenResource(shardedJedis);
                }
            }finally{
                shardedJedisPool.returnResource(shardedJedis);
            }
            String host = shardedJedis.getShardInfo(key).getHost();
            if(host.equals("192.168.99.233")) {
                num1 ++;
            }else if(host.equals("192.168.98.250")) {
                num2 ++;
            }else if(host.equals("192.168.96.48")) {
                num3 ++;
            }
            System.out.println(key + ":" + host);
        }
        System.out.println(num1);
        System.out.println(num2);
        System.out.println(num3);
    }

运行结果为：

328
333
339

jedis为每个节点建立了160个虚拟节点副本。从结果也可以看出均衡性是可以保证的。

另外JedisShardInfo的构造方法里还能指定该节点的权重占比，这样可以很方便地根据节点的性能差异来调整各自的权重。默认是1，设置其他数字之后，会给改节点建立 weight * 160个虚拟节点副本。

JedisShardInfo(String host, int port, int timeout, int weight)

有的时候我们会有这样的需求，同一类型的缓存需要保存在同一台redis上，方便管理和归档。比如所有用户的购物车缓存，或者某个应用下的所有特殊缓存，等。

如果用上面的示例代码，则会导致这些缓存分散在各个节点上。
而Jedis则提供了这个场景的解决方案。那就是创建ShardedJedisPool的时候指定一个keyTagPattern正则表达式。它会根据这个正则提取匹配到的字符串来进行hash处理。
（这里正则需要用到group这个概念，即“()”。正则我不是很熟，仅知道该这样用 - -！）
官方文档该功能介绍说明

举个例子，我们需要让所有”shopcart_${id}”这种类型的缓存存储到同一节点上，则将上述示例代码创建pool时作如下处理：

ShardedJedisPool shardedJedisPool = new ShardedJedisPool(gpoolConfig, shards, Pattern.compile("^(shopcart)"));

这样如果缓存key是以“shopcart”开头的，则在计算hash时用“shopcart”而不是完整的key。运行测试代码，得到的结果如下：

0
1000
0

所有的缓存都打在了第二个节点上。

2.4pre-sharding

上面我们说了利用一致性hash算法可以解决在扩容时导致全部缓存迁移的问题，只会导致部分缓存会命中不到原来的节点。那是否有办法让几乎所有的缓存都不会发生迁移呢？

这里就要讲到redis的作者给出的一个“机智”的方案了，那就是pre-sharding。
redis作者presharding博客

具体的方法思路就是：

1. 前期机器有限的时候，在一台机器上部署多个redis实例（先把坑占住）。redis实例占用的系统资源很小，小于1M，所以这种方案是可行的。
2. 在客户端集群中让所有的实例都参与hash。
3. 当需要扩容的时候，选择这台机器上的一个实例作为主节点，新机器上的redis作为从节点，复制主节点上的所有数据。
4. 数据备份完成之后，将配置文件中该节点替换成新机器上的redis，并将该节点提升为主节点，原旧节点可不再使用。
5. 需注意得让新旧节点的hash结果一致，否则不是我们期望的结果。所有节点用域名代替IP，替换时更换IP映射，这种方式比较好。

这就相当于是先给集群加入很多的节点，每个节点的存储空间都很小，后续需要扩容时就将某个小节点焕成空间大的节点，并继续保持key和缓存节点之间的映射关系。这样就完成了平滑扩容。

三.服务端集群

这部分待后续再研究… …

未完结… …