springboot が redis を統合してパーティションを変更する方法

springboot は redis を統合してパーティションを変更する

問題の原因

最近、springboot を使用して redis を統合し、システムの動的データ ソースがさまざまなデータベースに接続し、使用される redis をキャッシュします。次に、異なるデータベースのデータを Redis の異なるパーティション、つまり異なるライブラリにキャッシュする必要があります。

古いバージョンの解決策

ここでいう古いバージョンとは 2.0 より前のバージョンを指します。私が使用した 1.5.9 は問題ありません。

Redis 構成クラスはオンラインにたくさんあるため、ここには掲載しません。

1. JedisConnectionFactory を使用して

@Autowired
JedisConnectionFactory jedisConnectionFactory;
jedisConnectionFactory.setDatabase(database);

2. redisTemplate を使用して

redisTemplate.getConnectionFactory().getConnection().select(database);

を変更します。上記の 2 つの方法は、 require redis Bean は構成クラスに特別に追加されます

新しいバージョンのソリューション

ここでの新しいバージョンは 2.0 以降のバージョンを指します。私は 2.0.3 を使用しています

次のRedis 構成クラス Bean に追加する必要があります

@Bean
    RedisStandaloneConfiguration redisStandaloneConfiguration() {
        RedisStandaloneConfiguration redisStandaloneConfiguration = new RedisStandaloneConfiguration();
        redisStandaloneConfiguration.setHostName("localhost");
        redisStandaloneConfiguration.setPort(6379);
        redisStandaloneConfiguration.setDatabase(0);
        return redisStandaloneConfiguration;
    }
    @Bean
    JedisConnectionFactory jedisConnectionFactory(RedisStandaloneConfiguration redisStandaloneConfiguration) {
        //redisStandaloneConfiguration.setPassword(RedisPassword.of(password));
        JedisClientConfiguration.JedisClientConfigurationBuilder jedisClientConfiguration = JedisClientConfiguration.builder();
        jedisClientConfiguration.connectTimeout(Duration.ofMillis(0));//  connection timeout
        JedisConnectionFactory factory = new JedisConnectionFactory(redisStandaloneConfiguration,
                jedisClientConfiguration.build());
        return factory;
    }

RedisStandaloneConfiguration を使用して変更します

@Autowired
RedisStandaloneConfiguration redisStandaloneConfiguration;
redisStandaloneConfiguration.setDatabase(database);

redis パーティション

データが複数の Redis インスタンスに分散される方法

パーティショニングとは、各インスタンスにデータの一部のみが含まれるように、データを複数の Redis インスタンスに分散することです。

パーティショニングが役立つ理由

Redis パーティショニングには 2 つの主な目的があります:

1. これにより、より大きなデータベースが多数のコンピューターの合計メモリを使用できるようになります。パーティショニングを行わないと、メモリは 1 台のコンピュータに制限されます。

2. コンピューティング能力を複数のコアと複数のコンピューターに拡張し、ネットワーク帯域幅を複数のコンピューターとネットワーク アダプターに拡張することができます。

4 つの Redis インスタンス (R0、R1、R2、R3) があり、ユーザーを表す多くのキー (user:1、user:2、... など) があるとします。鍵を保管する方法はたくさんあります。

最も簡単な方法は、範囲によってパーティション化することです。つまり、オブジェクトのマッピング範囲に従って、指定された Redis インスタンスにデータを割り当てます。例えば、R0には0～10000、R1には10001～20000というIDを割り当てると規定します。この方法は可能ですが、欠点の 1 つは、このマッピング関係を維持するためにテーブルが必要であることです。このテーブルは管理する必要があり、各キーにはそのようなテーブルが 1 つ必要であるため、Redis での範囲パーティション分割は他のパーティション分割方法よりもはるかに効率が低いため、一般に嫌われています。

レンジ パーティショニングに加えて、ハッシュ パーティショニングという方法もあります。

ステップ 1、キーを取得し、ハッシュ関数を適用してそれを数値に変換します。たとえば、キーが foobar でハッシュ関数が crc32 の場合、 crc32(foobar) は 93024922 を出力します。

ステップ 2. この数値をモジュロ演算 (modulo) を使用して 0 から 3 までの直接数値に変換し、この数値を 4 つの Redis インスタンスの 1 つにマッピングできるようにします。たとえば、93024922 % 4 = 2 であるため、foobar は R2 インスタンスに保存される必要があります。

(追記: まず、キーに対してハッシュ演算を実行して数値を取得し、この数値の剰余を取得して、最終データをどのインスタンスに保存するかを決定します)

パーティショニングの方法にもたくさんの種類がありますが、上記の 2 つの例を通して理解できるはずです。ハッシュ パーティショニングの高度な形式はコンシステント ハッシュと呼ばれ、複数の Redis クライアントとブローカーによって実装されます。

異なるパーティションの実装

クライアント パーティション: 指定されたキーに対して、クライアントは読み取りおよび書き込み用に正しいノードを直接選択します。多くの Redis クライアントはクライアント側のパーティショニングを実装しています。

エージェント パーティション: クライアントはプロキシにリクエストを送信し、プロキシは Redis と通信します。プロキシは設定に基づいて正しい Redis インスタンスを選択します。

クエリ ルーティング: クエリを任意の Redis インスタンスに送信でき、インスタンスはクエリを正しいサーバーにリダイレクトします。

(追記: 特定のキーに対して、パーティショニングの仕事は正しい Redis インスタンスを選択することであり、この選択プロセスはクライアント、エージェント、または Redis インスタンスによって実行できます)

の欠点パーティショニング

1. 複数のキーを含む操作は通常サポートされません。 2 つの異なる Redis インスタンスにマップされたキーの場合、それらに対して挿入操作を実行することはできません。

2. Redis トランザクションは、複数のキーを含む操作には使用できません。

3. パーティションの粒度はキーであるため、単一の非常に巨大なキー (たとえば、非常に大きなキー) を変換することは不可能です。

#4. パーティションを使用すると、データ処理がより複雑になります。たとえば、複数の RDB/AOF ファイルを処理する必要があります。データをバックアップするには、永続性を集約する必要があります。複数のインスタンスおよびホストからのドキュメント。

5. 容量（スペース）の追加と削除はさらに複雑になります。たとえば、Redis Cluster は実行時にノードを追加および削除する透過的なデータ リバランスをサポートしていますが、クライアント パーティションやブローカーなどの他のシステムはこの機能をサポートしていません。ただし、これに関しては、プリシャーディングと呼ばれる手法が役に立ちます。

データ ストレージまたはキャッシュ?

Redis をデータ ストアとして使用する場合、特定のキーは常に同じ Redis インスタンスにマップされる必要があります。キャッシュとして使用する場合、特定のノードが使用できなくなっても大きな問題はありません。

特定のキーの優先ノードが利用できない場合、コンシステント ハッシュの実装は通常、他のノードに切り替えることができます。同様に、新しいノードが追加されると、新しいキーの一部が新しいノードに保存され始めます。

• Redis をキャッシュとして使用する場合は、一貫したハッシュを使用して簡単に拡張できます。

• Redis をストレージとして使用する場合、固定のキーとノードのマッピングが使用されるため、ノードの数は固定する必要があり、変更することはできません。 Redis Cluster は、ノード間でキーを再バランスする必要がある場合に有効なシステムです。

以上がspringboot が redis を統合してパーティションを変更する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。