Jedis一致性hash与sharding
=
=
=
Jedis一致性hash与sharding https://blog.csdn.net/javahongxi/article/details/79500755
一、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<MessageDigest> md5Holder = new ThreadLocal<MessageDigest>();
// 基于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<S> shards) {
nodes = new TreeMap<Long, S>();//虚拟节点，采取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<Long, S> 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<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();
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<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();
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<Object> all = pipeline.syncAndReturnAll();
for (Object e : all) {
System.out.println(e);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
sjp.returnResource(shardedJedis);
}
<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig"> <property name="maxActive" value="32"></property> <property name="maxIdle" value="6"></property> <property name="maxWait" value="15000"></property> <property name="minEvictableIdleTimeMillis" value="300000"></property> <property name="numTestsPerEvictionRun" value="3"></property> <property name="timeBetweenEvictionRunsMillis" value="60000"></property> <property name="whenExhaustedAction" value="1"></property> </bean> <bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool" destroy-method="destroy"> <constructor-arg ref="jedisPoolConfig"></constructor-arg> <constructor-arg> <list> <bean class="redis.clients.jedis.JedisShardInfo"> <constructor-arg value="127.0.0.1"></constructor-arg> <constructor-arg value="6379"></constructor-arg> <property name="password" value="0123456"></property> </bean> <bean class="redis.clients.jedis.JedisShardInfo"> <constructor-arg value="127.0.0.1"></constructor-arg> <constructor-arg value="6379"></constructor-arg> <property name="password" value="0123456"></property> </bean> </list> </constructor-arg> </bean>
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。
=
=
=
正文到此结束
- 本文标签： 配置 CTO 参数 Word IO 缓存 java struct map 代码 谷歌 删除 cache ArrayList ip zookeeper SDN list http bean sharding db API value client Action EXHAUSTED node 集群 IDE key build Property 一致性 tab cat redis 实例 企业 message jedispool web 线程 数据 程序员 同步 JMS id update UI App final ACE Master ssh https
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
