频道栏目
IT货架 > > 正文
Redis分布式
网友分享于:Jun 12, 2018 11:44:31 PM    来源: IT货架   

 

 

Redis-2.4.15目前没有提供集群的功能,Redis作者在博客中说将在3.0中实现集群机制。目前Redis实现集群的方法主要是采用一致性哈稀分片(Shard),和MemberCache一样,将不同的key分配到不同的redis server上,达到横向扩展的目的。下面来介绍一种比较常用的分布式场景:

 


在读写操作比较均匀且实时性要求较高,可以用下图的分布式模式:

在读操作远远多于写操作时,可以用下图的分布式模式:

       对于一致性哈稀分片的算法,Jedis-2.0.0已经提供了,下面是使用示例代码(以ShardedJedisPool为例):

package com.redis.client;import java.util.ArrayList;import java.util.List;import redis.clients.jedis.JedisPoolConfig;import redis.clients.jedis.JedisShardInfo;import redis.clients.jedis.ShardedJedis;import redis.clients.jedis.ShardedJedisPool;import redis.clients.util.Hashing;import redis.clients.util.Sharded;publicclass RedisShardPoolTest {static ShardedJedisPoolpool;static{JedisPoolConfig config =new JedisPoolConfig();//Jedis池配置config.setMaxActive(500);//最大活动的对象个数config.setMaxIdle(1000 * 60);//对象最大空闲时间config.setMaxWait(1000 * 10);//获取对象时最大等待时间config.setTestOnBorrow(true);String hostA = "10.10.224.44";int portA = 6379;String hostB = "10.10.224.48";int portB = 6379;List<JedisShardInfo> jdsInfoList =new ArrayList<JedisShardInfo>(2);JedisShardInfo infoA = new JedisShardInfo(hostA, portA);infoA.setPassword("redis.buy");JedisShardInfo infoB = new JedisShardInfo(hostB, portB);infoB.setPassword("redis.buy");jdsInfoList.add(infoA);jdsInfoList.add(infoB);pool =new ShardedJedisPool(config, jdsInfoList, Hashing.MURMUR_HASH,Sharded.DEFAULT_KEY_TAG_PATTERN);}/*** @param args*/publicstaticvoid main(String[] args) {for(int i=0; i<100; i++){String key = generateKey();//key += "{aaa}";ShardedJedis jds = null;try {jds = pool.getResource();System.out.println(key+":"+jds.getShard(key).getClient().getHost());System.out.println(jds.set(key,"1111111111111111111111111111111"));} catch (Exception e) {e.printStackTrace();}finally{pool.returnResource(jds);}}}privatestaticintindex = 1;publicstatic String generateKey(){return String.valueOf(Thread.currentThread().getId())+"_"+(index++);}}

 

从运行结果中可以看到,不同的key被分配到不同的Redis-Server上去了。

 

       实际上,上面的集群模式还存在两个问题:

1.       扩容问题:

因为使用了一致性哈稀进行分片,那么不同的key分布到不同的Redis-Server上,当我们需要扩容时,需要增加机器到分片列表中,这时候会使得同样的key算出来落到跟原来不同的机器上,这样如果要取某一个值,会出现取不到的情况,对于这种情况,Redis的作者提出了一种名为Pre-Sharding的方式:

Pre-Sharding方法是将每一个台物理机上,运行多个不同断口的Redis实例,假如有三个物理机,每个物理机运行三个Redis实际,那么我们的分片列表中实际有9个Redis实例,当我们需要扩容时,增加一台物理机,步骤如下:

A.     在新的物理机上运行Redis-Server;

B.      该Redis-Server从属于(slaveof)分片列表中的某一Redis-Server(假设叫RedisA);

C.      等主从复制(Replication)完成后,将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口;

D.     停止RedisA。

2.       单点故障问题:

还是用到Redis主从复制的功能,两台物理主机上分别都运行有Redis-Server,其中一个Redis-Server是另一个的从库,采用双机热备技术,客户端通过虚拟IP访问主库的物理IP,当主库宕机时,切换到从库的物理IP。只是事后修复主库时,应该将之前的从库改为主库(使用命令slaveof no one),主库变为其从库(使命令slaveof IP PORT),这样才能保证修复期间新增数据的一致性。

 

 

广告服务联系QQ:1134687142 | 网站地图

版权所有: IT货架- 内容来自互联网,仅供用于技术学习,请遵循相关法律法规. 京ICP备11030978号-1