elasticsearch fournit un riche ensemble d'interfaces d'appel Java vers le monde extérieur en construisant un client. De manière générale, les clients sont divisés en deux types : les clients d'informations de cluster et les clients de données (index). Ces deux catégories peuvent être divisées en opérations générales et opérations administratives.
(version 1.5, les autres versions peuvent être différentes) :
Grâce à ce diagramme de relation d'héritage, vous pouvez clairement comprendre la mise en œuvre et les fonctions du client. Il existe trois catégories au total, à savoir client, indicesAdminClient et ClusterAdminClient. Il possède sa propre classe d'implémentation, mais au final, il fournit des services externes via l'interface client. En tant qu'interface externe générale, le client combine d'abord les opérations liées à l'administration via la méthode admin(). Il fournit également toutes les opérations courantes sur les données et les clusters.
toutes les interfaces implémentent les appels asynchrones de deux manières, l'une consiste à renvoyer un ActionFuture et l'autre à accepter un ActionListener.
comme indiqué ci-dessous
ActionFuture
index(IndexRequest request) ; void index(IndexRequest request, ActionListener
listening);
La première méthode retournera un futur, la deuxième méthode doit passer un Listener. Ce sont également deux méthodes fondamentales de mise en œuvre asynchrone. Le client utilise le mode façade. Toutes les implémentations sont dans la classe AbstractClient. En prenant la méthode index comme exemple, le code est le suivant :
@Override public ActionFuture<IndexResponse> index(final IndexRequest request) { return execute(IndexAction.INSTANCE, request); } @Override public void index(final IndexRequest request, final ActionListener<IndexResponse> listener) { execute(IndexAction.INSTANCE, request, listener); }
L'implémentation est comme indiqué ci-dessus. La raison pour laquelle elle est appelée mode façade est parce que. toutes les méthodes sont intégrées au client, mais le processus d'exécution est exécuté dans l'action correspondante. Dans la méthode d'exécution, l'instance d'action correspondante est obtenue et la logique réelle est implémentée dans l'action de transaction correspondante.
est le suivant :
@SuppressWarnings("unchecked") @Override public <Request extends ActionRequest, Response extends ActionResponse, RequestBuilder extends ActionRequestBuilder<Request, Response, RequestBuilder, Client>> ActionFuture<Response> execute(Action<Request, Response, RequestBuilder, Client> action, Request request) { headers.applyTo(request); TransportAction<Request, Response> transportAction = actions.get((ClientAction)action); return transportAction.execute(request); } @SuppressWarnings("unchecked") @Override public <Request extends ActionRequest, Response extends ActionResponse, RequestBuilder extends ActionRequestBuilder<Request, Response, RequestBuilder, Client>> void execute(Action<Request, Response, RequestBuilder, Client> action, Request request, ActionListener<Response> listener) { headers.applyTo(request); TransportAction<Request, Response> transportAction = actions.get((ClientAction)action); transportAction.execute(request, listener); }
Chaque opération correspond à une transportAction correspondante, et ces transportActions sont les exécuteurs finaux. Ici, nous prenons l'index comme exemple pour une brève explication. Nous verrons plus de résultats comme celui-ci dans l'analyse de la fonction d'index plus tard.
public class IndexAction extends ClientAction<IndexRequest, IndexResponse, IndexRequestBuilder> { public static final IndexAction INSTANCE = new IndexAction(); public static final String NAME = "indices:data/write/index"; private IndexAction() { super(NAME); } @Override public IndexResponse newResponse() { return new IndexResponse(); } @Override public IndexRequestBuilder newRequestBuilder(Client client) { return new IndexRequestBuilder(client); } }
Dans IndexAction, il définit simplement un NOM et quelques méthodes simples. Ce nom sera enregistré dans TransportService comme clé du transportHandler au démarrage. Dans la méthode d'exécution, le transportAction sera retiré en fonction de l'action indiquée dans le code précédent. La véritable logique d'exécution se trouve dans InternalTransportClient. Son implémentation sera ignorée ici et sera analysée en détail plus tard. L'enregistrement de toutes ces actions est implémenté dans actionModule, et le processus d'enregistrement sera analysé ultérieurement avec l'action.
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!