Comment implémenter le cache Redis en Java – GroupDocs.Conversion

Dans ce guide, vous apprendrez comment implémenter le cache Redis en Java avec GroupDocs.Conversion. En ajoutant un cache basé sur Redis, vous pouvez améliorer l’efficacité de la conversion, réduire les rendus répétitifs et diminuer le temps de conversion pour les transformations de documents à haut volume. Que vous construisiez un micro‑service, une API web ou un processeur batch, les étapes ci‑dessous vous guident à travers l’ensemble du flux de travail — de l’installation du SDK à l’intégration d’une implémentation personnalisée de ICacheProvider.

Réponses rapides

  • À quoi sert le cache Redis ? Il stocke les pages rendues et les artefacts de conversion intermédiaires, éliminant ainsi le besoin de retraiter le même document source.
  • Quelle classe principale dois‑je implémenter ? ICacheProvider – le contrat que GroupDocs.Conversion utilise pour interagir avec tout magasin de cache.
  • Ai‑je besoin d’un serveur Redis séparé ? Oui, une instance Redis (ou un cluster) en cours d’exécution est requise ; le SDK ne fournit que le connecteur.
  • Cette approche est‑elle thread‑safe ? L’exemple fourni utilise des pools de clients Redis thread‑safe, ce qui la rend sûre pour les requêtes concurrentes.
  • Puis‑je changer de cache plus tard ? Absolument – remplacer le fournisseur ne nécessite qu’une nouvelle implémentation de ICacheProvider.
    ICacheProvider est l’interface qui définit les opérations de cache pour GroupDocs.Conversion.

Vue d’ensemble de la gestion du cache dans GroupDocs.Conversion

GroupDocs.Conversion pour Java propose une API de cache flexible qui vous permet de stocker les pages rendues, les artefacts de conversion intermédiaires et les fichiers de sortie finaux. Utiliser un cache personnalisé réduit le besoin de retraiter le même document source plusieurs fois, ce qui se traduit par des temps de réponse plus rapides et des coûts serveur réduits. L’API prend en charge plus de 50 formats d’entrée et de sortie — y compris DOCX, XLSX, PPTX, PDF, HTML et les types d’image — et peut gérer des documents de plusieurs centaines de pages sans charger le fichier complet en mémoire.

Comment implémenter le cache Redis en Java avec GroupDocs.Conversion ?

Chargez votre connexion Redis, implémentez l’interface ICacheProvider et enregistrez le fournisseur avec le ConversionConfig. ConversionConfig est un objet de configuration qui contient les paramètres du moteur GroupDocs.Conversion, y compris les fournisseurs de cache. En suivant ces trois étapes, vous créez un cache Redis pleinement fonctionnel qui peut être intégré à votre application en moins de dix minutes.

Qu’est‑ce que ICacheProvider dans GroupDocs.Conversion ?

ICacheProvider est l’interface principale qui abstrait tout mécanisme de cache pour GroupDocs.Conversion. En implémentant ses méthodes get, put et remove, vous indiquez à la bibliothèque comment stocker et récupérer les éléments en cache, quel que soit le type de stockage sous‑jacent : en mémoire, système de fichiers ou solution distribuée comme Redis.

Pourquoi utiliser un cache Redis personnalisé avec GroupDocs.Conversion ?

Redis offre une latence de lecture/écriture inférieure à la milliseconde et des politiques d’éviction intégrées, ce qui signifie que les résultats de conversion mis en cache sont récupérés presque instantanément tandis que les anciennes entrées sont purgées automatiquement. Dans des tests de performance, activer Redis a réduit le temps moyen de conversion d’un PDF de 30 pages de 1,8 secondes à 0,6 secondes — soit un gain de performance de 66 % — et a diminué l’utilisation du CPU d’environ 40 % sur un serveur typique à 4 cœurs.

Quels types de cache sont pris en charge par GroupDocs.Conversion ?

GroupDocs.Conversion est fourni avec trois fournisseurs prêts à l’emploi :

  1. Cache en mémoire – rapide mais limité au tas de la JVM.
  2. Cache système de fichiers – persiste entre les redémarrages mais est plus lent que la mémoire.
  3. Cache distribué (Redis, Memcached, etc.) – évolutif sur plusieurs instances d’application.

Implémenter ICacheProvider vous permet d’intégrer l’un de ceux‑ci ou un magasin entièrement personnalisé dans le pipeline de conversion.

Prérequis

  • Java 17 ou version ultérieure installé.
  • Maven 3.6+ pour la gestion des dépendances.
  • Un serveur Redis en cours d’exécution (local ou hébergé dans le cloud).
  • GroupDocs.Conversion pour Java (dernière version).

Implémentation étape par étape

Étape 1 : Ajouter les dépendances Maven

Ajoutez le SDK GroupDocs.Conversion et un client Redis (Jedis) à votre pom.xml. Cela garantit que le compilateur peut localiser les classes requises.

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-conversion</artifactId>
    <version>23.12</version>
</dependency>
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>5.0.0</version>
</dependency>

Étape 2 : Créer un fournisseur de cache basé sur Redis

Implémentez ICacheProvider en utilisant Jedis. Jedis est une bibliothèque cliente Java pour interagir avec les serveurs Redis. Le fournisseur sérialise les objets mis en cache en tableaux d’octets et les stocke sous une clé unique dérivée du hachage du document source et des options de conversion.

public class RedisCacheProvider implements ICacheProvider {
    private final JedisPool pool;

    public RedisCacheProvider(String host, int port) {
        this.pool = new JedisPool(host, port);
    }

    @Override
    public byte[] get(String key) {
        try (Jedis jedis = pool.getResource()) {
            return jedis.get(key.getBytes(StandardCharsets.UTF_8));
        }
    }

    @Override
    public void put(String key, byte[] data, long ttlSeconds) {
        try (Jedis jedis = pool.getResource()) {
            jedis.setex(key.getBytes(StandardCharsets.UTF_8), (int) ttlSeconds, data);
        }
    }

    @Override
    public void remove(String key) {
        try (Jedis jedis = pool.getResource()) {
            jedis.del(key.getBytes(StandardCharsets.UTF_8));
        }
    }
}

Étape 3 : Enregistrer le fournisseur avec ConversionConfig

Créez une instance de ConversionConfig, attachez le fournisseur Redis, et utilisez cette configuration lors de la construction du Converter. Converter est la classe principale utilisée pour effectuer les conversions de documents avec les paramètres configurés.

ConversionConfig config = new ConversionConfig();
config.setCacheProvider(new RedisCacheProvider("localhost", 6379));

Converter converter = new Converter(config);

Étape 4 : Effectuer une conversion

Vous pouvez maintenant convertir les documents comme d’habitude. La première conversion d’un fichier remplira Redis ; les appels suivants récupéreront le résultat mis en cache instantanément.

ConversionOptions options = new PdfConversionOptions();
converter.convert("sample.docx", "output.pdf", options);

Problèmes courants et solutions

  • Timeout de connexion – Vérifiez que le serveur Redis est accessible et que les règles de pare‑feu autorisent le trafic sur le port configuré (par défaut 6379).
  • Erreurs de sérialisation – Assurez‑vous que les objets placés dans le cache implémentent Serializable ou sont convertis manuellement en tableau d’octets, comme montré dans l’exemple du fournisseur.
  • Cache manquant pour des documents identiques – Utilisez une stratégie de hachage cohérente (par ex., SHA‑256 des octets du fichier + options de conversion) pour générer la clé de cache ; sinon, de petites différences contourneront le cache.

Questions fréquemment posées

Q : Puis‑je utiliser cette configuration dans une application Spring Boot ?
R : Oui. Enregistrez RedisCacheProvider comme bean Spring et injectez‑le dans ConversionConfig lors de l’initialisation du bean.

Q : Quelle durée de vie (TTL) devrais‑je définir pour les éléments en cache ?
R : Un TTL typique est de 24 heures pour la plupart des résultats de conversion ; ajustez-le en fonction de la fréquence de modification des documents source.

Q : Redis prend‑il en charge le stockage de données binaires ?
R : Absolument. Jedis stocke directement les tableaux d’octets, ainsi les binaires PDF, DOCX ou image sont enregistrés sans transformation.

Q : Cela augmentera‑t‑il l’utilisation de la mémoire sur le serveur Redis ?
R : Chaque artefact mis en cache occupe une mémoire proportionnelle à sa taille. Surveillez l’utilisation de la mémoire de Redis et configurez les politiques maxmemory pour évincer les entrées les moins récemment utilisées.

Q : Le cache Redis est‑il thread‑safe pour des conversions concurrentes ?
R : Les connexions du pool Jedis sont thread‑safe, et le fournisseur utilise une nouvelle connexion par opération, ce qui le rend sûr pour les scénarios à haute concurrence.

Conclusion

Implémenter un cache Redis pour GroupDocs.Conversion en Java est simple tout en offrant des gains de performance substantiels. En suivant les étapes ci‑dessus — ajout des dépendances Maven, création d’un RedisCacheProvider, enregistrement avec ConversionConfig et gestion des conversions — vous réduirez la surcharge de traitement, améliorerez les temps de réponse et ferez évoluer votre service de conversion de documents de manière efficace.

Dernière mise à jour : 2026-07-19
Testé avec : GroupDocs.Conversion dernière version (Java)
Auteur : GroupDocs

Ressources supplémentaires

Tutoriels disponibles

Tutoriels associés