Comment Springboot intègre-t-il Redis pour modifier les partitions

Springboot intègre redis pour modifier les partitions

L'origine du problème

Récemment, springboot est utilisé pour intégrer redis. Une source de données dynamique du système se connecte à différentes bases de données et met en cache les redis utilisés. Ensuite, les données des différentes bases de données doivent être mises en cache. dans différentes partitions Redis, c'est-à-dire différentes dans la bibliothèque.

Solution ancienne version

L'ancienne version ici fait référence à celle avant 2.0. La 1.5.9 que j'ai utilisée est ok.

La classe de configuration de redis ne sera pas publiée ici, il y en a beaucoup en ligne.

1. Utilisez JedisConnectionFactory pour modifier

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

2. Utilisez redisTemplate pour modifier

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

Les deux méthodes ci-dessus n'ont pas besoin d'ajouter spécifiquement des beans à la classe de configuration redis

Nouvelle solution de version

La nouvelle version ici fait référence à après 2.0 Oui, j'utilise 2.0.3

Les beans suivants doivent être ajoutés à la classe de configuration Redis

@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;
    }

Utilisez RedisStandaloneConfiguration pour modifier

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

partition redis

Comment les données sont distribuées sur plusieurs instances Redis

Le partitionnement est la façon dont vous répartissez les données sur plusieurs instances Redis afin que chaque instance ne contienne qu'une partie des données.

Pourquoi le partitionnement est utile

Le partitionnement Redis a deux objectifs principaux :

1. Il permet d'utiliser des bases de données plus volumineuses, en utilisant la mémoire combinée de plusieurs ordinateurs. Sans partitionnement, vous êtes limité à la mémoire d'un seul ordinateur.

2. Il permet d'étendre la puissance de calcul à plusieurs cœurs et plusieurs ordinateurs, et d'étendre la bande passante réseau à plusieurs ordinateurs et adaptateurs réseau.

Supposons que nous ayons 4 instances Redis (R0, R1, R2, R3), avec de nombreuses clés représentant les utilisateurs, telles que user:1, user:2, ... etc., alors lors du stockage d'une clé, il y en a beaucoup façons dont nous pouvons le faire.

Le moyen le plus simple consiste à partitionner par plage, c'est-à-dire à allouer les données à l'instance Redis spécifiée en fonction de la plage de mappage de l'objet. Par exemple, nous stipulons que les ID de 0 à 10 000 seront attribués à R0, de 10 001 à 20 000 à R1, etc. Cette méthode est possible, mais un inconvénient est qu'une table est nécessaire pour maintenir cette relation de mappage. Cette table doit être gérée et chaque clé nécessite une telle table, donc le partitionnement par plage dans Redis est généralement mal vu car il est beaucoup moins efficace que les autres méthodes de partitionnement.

En plus du partitionnement par plage, une autre méthode est le partitionnement par hachage :

Étape 1. Prenez la clé et appliquez une fonction de hachage pour la convertir en nombre. Par exemple, si la clé est foobar et que la fonction de hachage est crc32, alors crc32(foobar) affichera 93024922.

Étape 2. Utilisez l'arithmétique modulo (modulo) sur ce nombre pour le convertir en un nombre direct de 0 à 3, afin que ce nombre puisse être mappé à l'une de mes quatre instances Redis. Par exemple, 93024922 % 4 = 2, donc foobar doit être stocké sur l'instance R2.

(PS : faites d'abord une opération de hachage sur la clé pour obtenir un numéro, puis prenez le modulo de ce numéro pour déterminer sur quelle instance les données finales doivent être stockées)

Il existe de nombreuses façons de partitionner, à travers le au-dessus de deux exemples, vous devriez être capable de comprendre. Une forme avancée de partitionnement de hachage est appelée hachage cohérent et est implémentée par plusieurs clients et courtiers Redis.

Différentes implémentations de partition

Partitionnement client : pour une clé donnée, le client sélectionne directement le nœud correct pour la lecture et l'écriture. De nombreux clients Redis implémentent le partitionnement côté client.

Partition proxy : le client envoie une requête à un proxy et le proxy communique avec Redis. Le proxy sélectionnera la bonne instance Redis en fonction de notre configuration.

Routage des requêtes : vous pouvez envoyer votre requête à n'importe quelle instance Redis et l'instance redirigera votre requête vers le bon serveur.

(PS : pour une clé donnée, le travail de partitionnement consiste à sélectionner une instance Redis correcte, ce processus de sélection peut ensuite être effectué par le client, l'agent ou l'instance Redis)

Inconvénients du partitionnement

1 , Opérations impliquant plusieurs les clés ne sont généralement pas prises en charge. Pour les clés mappées à deux instances Redis différentes, vous ne pouvez pas effectuer d'opérations d'insertion sur celles-ci.

2. Les transactions Redis ne peuvent pas être utilisées pour des opérations impliquant plusieurs clés

3. La granularité de la partition est essentielle, il est donc impossible de diviser des données avec une seule clé très volumineuse (par exemple, un très grand ensemble trié)

4. , Lors de l'utilisation de partitions, le traitement des données sera plus compliqué. Pour les instances, vous devez traiter plusieurs fichiers RDB/AOF. Afin de sauvegarder les données, les fichiers persistants doivent être agrégés à partir de plusieurs instances et hôtes.

5. L'ajout et la suppression de capacité (espace) deviennent plus compliqués. Par exemple, Redis Cluster prend en charge le rééquilibrage transparent des données qui ajoute et supprime des nœuds au moment de l'exécution, mais d'autres systèmes tels que les partitions client et les courtiers ne prennent pas en charge cette fonctionnalité. Cependant, une technique appelée pré-sharding est utile à cet égard.

Stockage ou mise en cache des données ?

Lorsque Redis est utilisé comme magasin de données, une clé donnée doit toujours être mappée à la même instance Redis. Lorsqu'il est utilisé comme cache, ce n'est pas un gros problème si un nœud donné devient indisponible.

Les implémentations de hachage cohérentes sont généralement capables de basculer vers d'autres nœuds si le nœud préféré pour une clé donnée n'est pas disponible. De même, si un nouveau nœud est ajouté, certaines des nouvelles clés commenceront à être stockées sur le nouveau nœud.

• Si vous utilisez Redis comme cache, il est facile de le mettre à l'échelle en utilisant un hachage cohérent.

• Si Redis est utilisé comme stockage, un mappage clés-nœuds fixe est utilisé, le nombre de nœuds doit donc être fixe et ne peut pas être modifié. Redis Cluster est un système viable si les clés doivent être rééquilibrées entre les nœuds.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!