Configuration de l'invalidation de cache à distance
A l'aide d'Apache Kafka et d'Apache ZooKeeper, vous pouvez exécuter l'invalidation du cache à partir du HCL CommerceTransaction server ou à distance à partir d'un serveur Liberty. Vous pouvez activer et personnaliser cette fonction en modifiant les fichiers de configuration HCL Commerce.
Avant de commencer
HCL Commerce La version 9 utilise Apache Kafka et Apache ZooKeeper pour synchroniser de manière transparente les données sur plusieurs serveurs. La procédure suivante suppose que vous disposez d'installations fonctionnelles des deux produits sur votre réseau.
Important : Installez et exécutez Kafka et ZooKeeper en tant que serveurs isolés dans des conteneurs Docker dédiés. Aucune des deux applications n'est associée à HCL Commerce. Configurez Kafka à l'aide de variables Vault ou d'environnement.
Voici un exemple pour définir les variables d'environnement :
Remarque :Si vous souhaitez établir une communication sécurisée avec Kafka, vous pouvez utiliser le paramètre facultatif fourni. Voici un exemple pour définir les variables d'environnement :
Si la chaîne <KafkaServers> commence par (no-crs), alors Transaction server ne publiera pas les messages d'invalidation destinés à être reçus par le Store server.
Remarque : Si les conteneurs, tels que DB2 et TS-App, se trouvent dans des fuseaux horaires distincts lors de la définition de Kafka/ Zookeeper dans v9, les invalidations risquent de ne pas se produire correctement. Dans les propriétés Kafka, assurez-vous que log.message.timestamp.type = LogAppendTime. Par défaut, cette valeur est définie sur log.message.timestamp.type = CreateTime.
Le mot de passe d'authentification Kafka doit être la chaîne chiffrée à l'aide de wcs_encrypt password. La chaîne chiffrée ASCII doit être enregistrée dans le fichier de configuration, avec le mot de passe de Sasl des serveurs Kafka.
Pourquoi et quand exécuter cette tâche
Effectuez les procédures suivantes pour activer l'invalidation du cache à distance :
Si l'annuaire ou le fichier de configuration n'existent pas, créez-les.
Créez le répertoire.
Accédez au chemin suivant.
workspace_dir\WC\xml\config\
Créez le répertoire extension.
com.ibm.commerce.foundation-ext
Créez le fichier de configuration personnalisé dans le répertoire extension.
Accédez au répertoire extension, workspace_dir\WC\xml\config\com.ibm.commerce.foundation-ext\.
Créez un fichier wc-component.xml vide dans le dossier com.ibm.commerce.component_name-ext. Ce fichier est votre fichier wc-component.xml personnalisé.
Ajoutez les éléments XML de base requis pour votre fichier wc-component.xml personnalisé.
Ouvrez votre fichier personnalisé wc-component.xml vide dans un éditeur XML.
Copiez le contenu du fichier de configuration par défaut dans votre fichier de configuration personnalisé (workspace_dir\WC\xml\config\com.ibm.commerce.foundation\wc-component.xml), ou créez-le à partir de zéro en copiant le code suivant dans le fichier :
Important : Ne modifiez pas les propriétés directement dans ce fichier, car vos modifications seraient écrasées pas les mises à jour ultérieures des produits HCL.
Copiez les éléments XML des propriétés du fichier de configuration de composant par défaut que vous souhaitez modifier vers votre fichier wc-component.xml personnalisé. Insérez les éléments XML copiés après l'élément <_config:extendedconfiguration>.
Même si vous ne copiez que certains éléments, vous devez conserver leur hiérarchie XML dans le fichier. Par exemple, si vous souhaitez modifier la propriété définie dans un élément <_config:property> spécifique, vous devez conserver les éléments parent et ancêtre de l'élément <_config:property>, mais vous pouvez supprimer tous les objets de même niveau si vous ne les modifiez pas. Consultez l'exemple à la fin de cette rubrique.
S'il n'existait pas auparavant, votre fichier de configuration personnalisé est maintenant créé et prêt à être personnalisé ultérieurement.
Localisez le paramètre wc.store.remote.kafka du regroupement de configuration RemoteStoreConfiguration. Ajoutez les adresses des clusters de courtier Apache Kafka, en tant que chaîne séparée par virgule, à l'attribut valeur. Définissez les numéros de port en fonction de votre environnement local. Par exemple :
<_config:configgrouping name="RemoteStoreConfiguration">
...
<!-- value to kafka servers connection string -->
<_config:property name="wc.store.remote.kafka" value="kafka-broker1:9092,kafka-broker2:9092,kafka-broker3:9092"/>
...
</_config:configgrouping>
Localisez le paramètre wc.store.remote.kafka.topicPrefix dans le même regroupement de configuration. Ajoutez le préfixe du sujet pour l'invalidation du cache. Cette chaîne contient la même valeur que le préfixe configuré dans le serveur de magasin distant. La valeur doit être identique sur tous les serveurs de transactions.
<!-- value to kafka servers topic prefix -->
<_config:property name="wc.store.remote.kafka.topicPrefix" value="sampleprefix"/>
Localisez le paramètre wc.remote.zookeeper du regroupement de configuration TransactionKafkaConfiguration. Ajoutez les adresses des serveurs Apache ZooKeeper, en tant que chaîne séparée par virgule, à l'attribut valeur. Définissez les numéros de port en fonction de votre environnement local. Par exemple :
Modifier le fichier de configuration personnalisé jndi.xml. Si le fichier n'existe pas, créez-le.
Ajoutez la chaîne de configuration des serveurs ZooKeeper à l'attribut jndiName de l'élément jndiEntry. La valeur est la même que la chaîne de configuration ZooKeeper dans le Transaction server.
La conservation des messages par défaut est de 7 jours, ce qui est très excessif lorsque les messages ne sont plus nécessaires après le traitement des invalidations de cache par toutes les applications. Un délai de conservation de 10 minutes est suffisant pour la plupart des configurations.
Désactiver la configuration automatique des sujets
Par défaut, si un message est envoyé à un sujet qui n'est pas déjà configuré, Kafka le crée automatiquement. Cette approche entraîne un défaut de définition de configurations telles que la conservation des messages et le facteur de réplication, ce qui peut entraîner des problèmes d'indisponibilité. Pour éviter de tels problèmes, désactivez la configuration automatique des sujets. Cela force le client à configurer des sujets avec les paramètres que vous avez définis.
Utiliser des répliques
Les répliques offrent une haute disponibilité. Par exemple, avec deux courtiers, la configuration peut être la suivante :
Utilisez les paramètres suivants avec les producteurs :
//acks=all, This means the leader will wait for the full set of in-sync replicas to acknowledge the record.
//This guarantees that the record will not be lost as long as at least one in-sync replica remains alive.
configValues.put(ProducerConfig.ACKS_CONFIG, "all");
// Setting a value greater than zero will cause the client to resend any record whose send fails with a potentially transient error.
configValues.put(ProducerConfig.RETRIES_CONFIG, 0);
//The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition.
configValues.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
//LINGER_MS_CONFIG, This setting gives the upper bound on the delay for batching.
configValues.put(ProducerConfig.LINGER_MS_CONFIG, 1);
//buffer.memory, The total bytes of memory the producer can use to buffer records waiting to be sent to the server.
configValues.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 33554432);
Utilisez les paramètres suivants avec les consommateurs :
//ENABLE_AUTO_COMMIT_CONFIG : If true, periodically commit to Kafka the offsets of messages already returned by the consumer.
configValues.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
// AUTO_OFFSET_RESET_CONFIG : earliest: automatically reset the offset to the earliest offset
configValues.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
Notez que puisque chaque serveur définit son propre groupe de consommateurs (configuration de consommateur unique) et que tous les messages sont stockés avec une clé statique, une partition unique est utilisée. Cela garantit que les messages sont reçus dans le même ordre selon lequel ils ont été créés.
Exemple
Vous pouvez examiner le contenu de vos messages en utilisant Kafdrop, ou utiliser kafka-manager pour gérer le sujet et les courtiers. Les messages ont le format suivant, selon la transaction.
Les messages Transaction server à Transaction server présentent le format suivant :Les messages entre un serveur de transactions et un serveur de magasin ont un format similaire :
Que faire ensuite
Pour améliorer les performances et optimiser les données pour l'analyse, vous pouvez activer, désactiver et personnaliser les paramètres de cache individuels. Les DistributedMaps des serveurs de transactions et de magasin suivants sont pertinentes pour Kafka.
Si vous souhaitez établir une communication sécurisée avec Kafka, vous pouvez utiliser le paramètre facultatif fourni. Voici un exemple pour définir les variables d'environnement :
