Jedis一致性hash与sharding

阅读更多

    一、Jedis一致性hash

    利用缓存技术,不仅可以提升系统性能,还能缓解系统故障。对于redis 3.0以下的版本,redis-server没有sharding的功能,只有master-slave模式。目前企业用的普遍都是只有m/s模式的redis多实例部署,无论是master还是slave挂掉,都需要调整程序配置(或代码)。Jedis为我们提供了编程级别的sharding方式,本文主要介绍相关API使用方法。

 

     Jedis中sharding基于一致性hash算法,hash值计算采取MD5作为辅助,此算法似乎已成事实上的标准,不过较新的版本采用的是谷歌的murmur_hash算法(MD5 is really not good?)。

 

public interface Hashing {
  public static final Hashing MURMUR_HASH = new MurmurHash();
  public ThreadLocal md5Holder = new ThreadLocal();
         // 基于MD5的一致性hash算法实现
  public static final Hashing MD5 = new Hashing() {
    public long hash(String key) {
      return hash(SafeEncoder.encode(key));
    }

    public long hash(byte[] key) {
      try {
        if (md5Holder.get() == null) {
          md5Holder.set(MessageDigest.getInstance("MD5"));
        }
      } catch (NoSuchAlgorithmException e) {
        throw new IllegalStateException("++++ no md5 algorythm found");
      }
      MessageDigest md5 = md5Holder.get();

      md5.reset();
      md5.update(key);
      byte[] bKey = md5.digest(); // 获得MD5字节序列
      // 前四个字节作为计算参数,最终获得一个32位int值.  
      // 此种计算方式,能够确保key的hash值更加“随即”/“离散”  
      // 如果hash值过于密集,不利于一致性hash的实现(特别是有“虚拟节点”设计时) 
      long res = ((long) (bKey[3] & 0xFF) << 24) | ((long) (bKey[2] & 0xFF) << 16)
          | ((long) (bKey[1] & 0xFF) << 8) | (long) (bKey[0] & 0xFF);
      return res;
    }
  };

  public long hash(String key);

  public long hash(byte[] key);
}

 

    node构建过程:

//shards列表为客户端提供了所有redis-server配置信息,包括:ip,port,weight,name
//其中weight为权重,将直接决定“虚拟节点”的“比例”(密度),权重越高,在存储是被hash命中的概率越高
//--其上存储的数据越多。
//其中name为“节点名称”,jedis使用name作为“节点hash值”的一个计算参数。
//---
//一致性hash算法,要求每个“虚拟节点”必须具备“hash值”,每个实际的server可以有多个“虚拟节点”(API级别)
//其中虚拟节点的个数= “逻辑区间长度” * weight,每个server的“虚拟节点”将会以“hash”的方式分布在全局区域中
//全局区域总长为2^32.每个“虚拟节点”以hash值的方式映射在全局区域中。
// 环形:0-->vnode1(:1230)-->vnode2(:2800)-->vnode3(400000)---2^32-->0
//所有的“虚拟节点”将按照其”节点hash“顺序排列(正序/反序均可),因此相邻两个“虚拟节点”之间必有hash值差,
//那么此差值,即为前一个(或者后一个,根据实现而定)“虚拟节点”所负载的数据hash值区间。
//比如hash值为“2000”的数据将会被vnode1所接受。
//---
private void initialize(List shards) {
	nodes = new TreeMap();//虚拟节点,采取TreeMap存储:排序,二叉树

	for (int i = 0; i != shards.size(); ++i) {
	    final S shardInfo = shards.get(i);
	    if (shardInfo.getName() == null)
                //当没有设置“name”是,将“SHARD-NODE”作为“虚拟节点”hash值计算的参数
                //"逻辑区间步长"为160,为什么呢??
                //最终多个server的“虚拟节点”将会交错布局,不一定非常均匀。
	    	for (int n = 0; n < 160 * shardInfo.getWeight(); n++) {
	    		nodes.put(this.algo.hash("SHARD-" + i + "-NODE-" + n), shardInfo);
	    	}
	    else
	    	for (int n = 0; n < 160 * shardInfo.getWeight(); n++) {
	    		nodes.put(this.algo.hash(shardInfo.getName() + "*" + shardInfo.getWeight() + n), shardInfo);
	    	}
	    resources.put(shardInfo, shardInfo.createResource());
	}
}

 

    node选择方式:

public R getShard(String key) {
	return resources.get(getShardInfo(key));
}
//here:
public S getShardInfo(byte[] key) {
        //获取>=key的“虚拟节点”的列表
	SortedMap tail = nodes.tailMap(algo.hash(key));
        //如果不存在“虚拟节点”,则将返回首节点。
	if (tail.size() == 0) {
	    return nodes.get(nodes.firstKey());
	}
        //如果存在,则返回符合(>=key)条件的“虚拟节点”的第一个节点
	return tail.get(tail.firstKey());
}

 

    Jedis sharding默认的一致性hash算法比较适合cache-only的情景,不太适合数据持久化情况。在持久存储情况下,我们可以使用“强hash”分片,需要重写hash算法(参加后面的InnerHashing)。强hash算法下,如果某个虚拟节点所在的物理节点故障,将导致数据无法访问,即无法从虚拟节点列表中删除失效的server。

 

    二、API

    ShardedJedis

        JedisShardInfo sd1 = new JedisShardInfo("127.0.0.1", 6379, 15000);
        sd1.setPassword("123456");
        JedisShardInfo sd2 = new JedisShardInfo("127.0.0.1", 6479, 15000);
        sd2.setPassword("123456");
        List shards = new ArrayList();
        shards.add(sd1);
        shards.add(sd2);
        ShardedJedis shardedJedis = new ShardedJedis(shards, new InnerHashing());
        String key = "k2sdjowejjroer3";
        shardedJedis.set(key, "v2");
        Charset charset = Charset.forName("utf-8");
        // 注意此处对key的字节转换时,一定要和Innerhashing.hash(String)保持一致
        System.out.println(shardedJedis.get("k2").getBytes(charset));

// Jedis的一致性hash算法已经足够良好,程序员建议不要重写
public class InnerHashing implements Hashing {
    static Charset charset = Charset.forName("utf-8");

    @Override
    public long hash(String key) {
        return hash(key.getBytes(charset));
    }

    @Override
    public long hash(byte[] key) {
        int hashcode = new HashCodeBuilder().append(key).toHashCode();
        return hashcode & 0x7FFFFFFF;
    }
}

 


	
		
			
				
				
				
			
			
				
				
				
			
		
	

 

     ShardedJedisPool & ShardedJedisPipeline

        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(32);
        config.setMaxIdle(6);
        config.setMinIdle(0);
        config.setMaxWaitMillis(15000);

        JedisShardInfo sd1 = new JedisShardInfo("127.0.0.1", 6379, 15000);
        sd1.setPassword("123456");
        JedisShardInfo sd2 = new JedisShardInfo("127.0.0.1", 6479, 15000);
        sd2.setPassword("123456");
        List shards = new ArrayList();
        shards.add(sd1);
        shards.add(sd2);

        ShardedJedisPool sjp = new ShardedJedisPool(config, shards);
        ShardedJedis shardedJedis = sjp.getResource();
        try {
            System.out.println(shardedJedis.get("k2"));

            ShardedJedisPipeline pipeline = new ShardedJedisPipeline();
            pipeline.setShardedJedis(shardedJedis);
            pipeline.set("k4", "v4");
            pipeline.set("k5", "v5");
            pipeline.get("k5");
            List all = pipeline.syncAndReturnAll();
            for (Object e : all) {
                System.out.println(e);
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            sjp.returnResource(shardedJedis);
        } 
  

 


	
	
	
	
	
	
	


	
	
		
			
				
				
				
			
			
				
				
				
			
		
	

    

    Something:

redis以及其他类似的网络IO server,实现绝对意义上的自动扩容(server端)和自动探测与rebalance,是很难的,同时也有一些风险.

我们现在的做法也比较土:
1) 有个web portal系统,当一个redis实例部署好之后,就是web系统上输入它的IP地址和探测脚本(脚本用来检测redis的内存负载情况,存活情况).
2) 录入之后可以将此redis"上线/下线",即将redis信息同步到zookeeper中(俗称configserver);
3) 所有redis-client端,都接入configserver,获取可用的redis列表;并初始化redis-client.
4) redis-client有一个额外的线程用来与configserver保持通讯,实时的跟踪redis列表的变更.
5) 如果redis列表变更,将导致redis-client端重新调整,主要是重建"一致性hash表".
6) 重建"一致性hash表"的过程,不需要调整代码或者重启服务,这个和hash的设计方式有些关系.

简单的来说,你可以使用任何方式(db,或者JMS订阅)来获取redis集群节点的变更数据即可..对于"客户端一致性hash表"的设计,也需要有些技巧,最好不要因为一个节点的join或者remove,导致大面积缓存的命中失败..

程序中通过合理的配置和编码,我们可以实现写master读slave。

 本人通过查看公司应用系统的监控表明,redis几乎保持 set 2ms get 1ms, sql最快时 count 2ms select 3ms add/update 5ms

 

你可能感兴趣的:(jedis,sharding)