Redis分散クラスタ

Redis-2.4.15は現在クラスタの機能を提供していないが、Redisの著者らはブログで3.0でクラスタメカニズムを実現すると述べた.現在Redisがクラスタを実現する方法は,主にコンシステンシハッシュスライス(Shard)を用いて,異なるkeyを異なるredis serverに割り当て,横方向拡張の目的を達成している.一般的な分散シーンについて説明します.
読み書き操作が比較的均一でリアルタイム性の要求が高い場合、下図の分散モードを使用できます.
読み取り操作が書き込み操作よりはるかに多い場合は、次の図の分散モードを使用します.
コンシステンシハスキースライスのアルゴリズムについては、Jedis-2.0.0が提供されています.次に、サンプルコード(ShardedJeddisPoolを例に挙げる)を使用します.

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.password");
        JedisShardInfo infoB = new JedisShardInfo(hostB, portB);
        infoB.setPassword("redis.password");
        jdsInfoList.add(infoA);
        jdsInfoList.add(infoB);
        pool =new ShardedJedisPool(config, jdsInfoList, Hashing.MURMUR_HASH,Sharded.DEFAULT_KEY_TAG_PATTERN);
    }

    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++);

    }
}

実行結果から、異なるキーが異なるRedis-Serverに割り当てられていることがわかります.
実際には、上記のクラスタモードには2つの問題があります.
1.拡張問題:
コンシステンシハッシュを使用してスライスすると、異なるkeyが異なるRedis-Serverに分布し、拡張が必要な場合、スライスリストにマシンを追加する必要があるため、同じkeyを元の異なるマシンに計算して落とすことができ、ある値を取ると取れない場合があり、この場合、Redisの著者らはPre-Shardingという方法を提案した.
Pre-Shardingメソッドは、各物理マシンで複数の異なるブレークスルーのRedisインスタンスを実行し、3つの物理マシンがある場合、各物理マシンで3つのRedis実績を実行すると、私たちのスライスリストには実際に9つのRedisインスタンスがあり、拡張が必要な場合、1台の物理マシンを追加し、次のようにします.
A.新しい物理マシンでRedis-Serverを実行する.
B.当該Redis-Serverは、スライスリストに属するあるRedis-Server(RedisAと仮定する)に属する.
C.等主従レプリケーションが完了した後、クライアントスライスリストのRedisAのIPとポートを新しい物理マシン上のRedis-ServerのIPとポートに変更する.
D.RedisAを停止します.
これは、あるRedis-Serverを新しいマシンに移行することに相当します.Prd-Shardingは実際にはオンライン拡張の方法ですが、Redis自体のレプリケーション機能に依存しています.プライマリ・ライブラリのスナップショット・データ・ファイルが大きすぎると、このレプリケーションのプロセスも長くなり、プライマリ・ライブラリに圧力をかけます.したがって、この分割のプロセスは、ビジネスアクセスの低ピーク期間のために行うことが望ましい.
2.単一障害の問題:
また、Redisプライマリスレーブレプリケーションの機能を使用して、2台の物理ホスト上でそれぞれRedis-Serverが実行され、そのうちの1つのRedis-Serverは別のスレーブライブラリであり、デュアルマシンホットスペア技術を採用し、クライアントは仮想IPを通じてプライマリライブラリの物理IPにアクセスし、プライマリライブラリがダウンタイムした場合、スレーブライブラリの物理IPに切り替える.ただし、後でマスターライブラリを修復する場合は、以前のスレーブライブラリをマスターライブラリ(コマンドslabeof no oneを使用)に変更し、マスターライブラリをスレーブライブラリ(コマンドslabeofIP PORT)に変更することで、修復期間中の新規データの一貫性を保証できます.
移動先:http://blog.csdn.net/freebird_lb/article/details/7778999