introduction

Dans Apache Geode, qui est l'une des implémentations KVS de type système distribué, il est courant d'utiliser une fonction appelée Exécution de fonction lorsque vous souhaitez exécuter une logique côté serveur. Cependant, comme Functoin Execution est hautement fonctionnel, la quantité de codage autre que les éléments de réglage et la logique réelle a tendance à être importante, et la logique spécifique n'est exécutée qu'une seule fois sur l'un des nœuds du serveur de cache, quelle que soit la disposition des données dans le cluster et renvoyée. Il peut être un peu intimidant à utiliser dans des cas simples où aucune valeur n'est requise.

Dans cet article, je vais vous montrer comment exécuter plus facilement la logique côté serveur avec Apache Geode sans utiliser la fonction Function Execution. Ci-après, l'entité qui exécute une logique arbitraire sera appelée "commande". La méthode de cet article a été confirmée pour fonctionner avec Apache Geode 1.6.0.

Objectif

Dans cet article, en tant qu'exemple d'exécution logique côté serveur simple, le contenu suivant sera défini et implémenté sans utiliser la fonction d'exécution de fonction.

--Exécutez la commande pour supprimer toutes les données dans la région spécifiée (c'est-à-dire exécutez `` Regoin # clear '') une seule fois sur n'importe quel nœud de serveur de cache du cluster, pas de valeur de retour

Comment ça fonctionne

La logique est exécutée côté serveur sans utiliser la fonction d'exécution de fonction par le mécanisme suivant.

Préparez une région dédiée pour exécuter la logique (ci-après, région de commande) - Une région proxy convient car elle ne stocke pas de données (`` refid = REPLICATED_PROXY '')
Dans la zone Command, l'objet de commande est défini comme valeur. La touche `` put '' n'est pas utilisée, donc aucune valeur.
Exécutez la commande passée en tant que valeur avec `` CacheWriter '' qui était précédemment affectée à la région Command côté serveur.

Ici, la raison d'utiliser CacheWriter '' au lieu du CacheListner '' couramment utilisé est que le premier permet essentiellement à tous les serveurs de cache assignés de réagir et à la commande d'être exécutée deux fois. En effet, ce dernier s'exécute sur l'un des serveurs de cache accordés, alors qu'il est sexuel.

Pour référence, le diagramme d'image d'exécution est affiché ci-dessous.

Créer une commande

En tant que politique, en supposant qu'une classe est préparée individuellement pour chaque commande, l'interface de commande suivante est définie afin de standardiser la logique d'exécution des commandes avec `` CacheWriter ''.

`Command.java`


public interface Command {
  public void process();
}

Ensuite, sous la forme de l'implémentation, écrivez la classe de commande de suppression de données de la région spécifiée comme suit. Exécutez Region # clear '' avec la méthode process '' définie dans l'interface de commande en fonction de la région (`` regionName '') spécifiée lors de l'instanciation de cette classe de commande.

`ClearRegionCommand.java`


import org.apache.geode.cache.CacheFactory;
import org.apache.geode.cache.Region;

import java.io.Serializable;

public class ClearRegionCommand implements Command, Serializable {
  private String regionName;
  
  public ClearRegionCommand(String regionName) {
    this.regionName = regionName;
  }
  
  public void process() {
    Region region = CacheFactory.getAnyInstance().getRegion(this.regionName);
    if (region != null) {
      region.clear();
    }
  }
}

Notez que l'objet de commande lui-même est envoyé au serveur via le réseau, il doit donc être implémenté en tant qu'objet sérialisable. Ici, nous avons déjà implémenté `` java.io.Serializable '', mais comme il s'agit d'Apache Geode, vous pouvez utiliser PDX comme technologie de sérialisation d'objets.

Et l'implémentation de CacheWriter '' qui exécute la commande. Dans la méthode beforeCreate, récupérez l'objet de commande à partir de l'événement généré par put '' et exécutez la méthode process ''. À propos, CacheWriter '' est souvent défini dans le fichier de configuration du cache (ci-après, cache.xml), et `` Déclarable '' est implémenté au cas où.

`ProcessCommandCacheWriter.java`


import org.apache.geode.cache.Cache;
import org.apache.geode.cache.CacheWriterException;
import org.apache.geode.cache.Declarable;
import org.apache.geode.cache.EntryEvent;
import org.apache.geode.cache.util.CacheWriterAdapter;

import java.util.Properties;

public class ProcessCommandCacheWriter extends CacheWriterAdapter<Integer,Command> implements Declarable {
  public void beforeCreate(EntryEvent<Integer,Command> event) throws CacheWriterException {
    Command command = event.getNewValue();
    command.process();
  }

  public void initialize(Cache cache, Properties properties) { }

  public void close() {}
}

Paramètres de `` CacheWriter ''

Ici, il est défini à l'aide de cache.xml. Il sera affecté à la région de commande où REPLICATE_PROXY est défini dans refid. La région exemple sera la région exemple à exécuter par la commande implémentée cette fois, `` Regoin # clear ''.

`cache.xml`


<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://geode.apache.org/schema/cache"
       xsi:schemaLocation="http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"
       version="1.0" lock-lease="120" lock-timeout="60" search-timeout="300" is-server="false" copy-on-read="false">

    <cache-server port="0" />

    <region name="Example" refid="REPLICATE" />

    <region name="Command" refid="REPLICATE_PROXY">
        <region-attributes>
            <cache-writer>
                <class-name>ProcessCommandCacheWriter</class-name>
            </cache-writer>
        </region-attributes>
    </region>
</cache>

Réglage CLASSPATH

Les commandes entrées par le client sont exécutées sur le serveur, vous devez donc définir le chemin vers diverses classes associées dans le CLASSPATH du serveur. Le corps de la classe de commande (ici, ClearRegionCommand '') peut être défini dynamiquement avec la commande gfsh deploy '' si nécessaire, mais au moins le chemin vers les classes suivantes doit être défini lors du démarrage du serveur. Il y a.

Classe CacheWriter (ici, classe ProcessCommandCacheWriter)
Interface de commande (ici, interface de commande)

L'interface ne semble pas pouvoir définir CLASSPATH avec la commande `` gfsh deploy ''

Entrée de commande du client

Créez un objet de commande et codez-le dans la région Command en tant que valeur `` put '' comme suit:

ClientCache cache = new ClientCacheFactory()
  .set("cache-xml-file", "client-cache.xml")
  .create();
cache.getRegion("Command").put(0, new ClearRegionCommand("Example"));

Pour référence, voici un exemple de cache.xml côté client.

`client-cache.xml`


<?xml version="1.0" encoding="UTF-8"?>
<client-cache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://geode.apache.org/schema/cache"
       xsi:schemaLocation="http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"
       version="1.0" copy-on-read="false">

    <pool name="MyPool" subscription-enabled="true">
        <locator host="xxx.xxx.xxx.xxx" port="xxxxx" />
    </pool>

    <region name="Example">
        <region-attributes pool-name="MyPool" refid="CACHING_PROXY" />
    </region>

    <region name="Command">
        <region-attributes pool-name="MyPool" refid="PROXY" />
    </region>
</client-cache>

finalement

En le résumant sous forme d'article, je pense qu'il y a plus de codes et de paramètres que ce à quoi je m'attendais dans le cas de Function Executoin, mais je pense qu'il est facile pour les utilisateurs de saisir les commandes du client sur une seule ligne. Je suis.

De plus, avec la méthode introduite cette fois, en ajoutant le paramètre Gateway Sender à la région Command, il est possible d'exécuter l'exploit d'exécuter une logique arbitraire même dans un autre cluster avec le récepteur de passerelle défini via le WAN. Si vous êtes intéressé et en demande, essayez-le.

[JAVA] Apache Geode-Easy moyen d'exécuter la logique côté serveur