ES學(xué)習(xí)筆記之--delete api的實(shí)現(xiàn)流程

ES的delete api使用非常簡(jiǎn)單。

curl -XDELETE 'http://localhost:9200/index/type/doc_id'

前面學(xué)習(xí)了get api的主要流程，這里探索一下delete api的實(shí)現(xiàn)原理。 優(yōu)先選擇delete api而非index api, 主要是覺(jué)得刪除貌似更容易， 選擇delete api學(xué)習(xí)曲線應(yīng)該比較平緩。

ES相關(guān)功能Action的命名很統(tǒng)一， 比如get api, 對(duì)應(yīng)實(shí)現(xiàn)類的名稱為TransportGetAction, delete api對(duì)應(yīng)實(shí)現(xiàn)類的名稱也是依樣畫葫蘆: TransportDeleteAction。

但是學(xué)習(xí)TransportDeleteAction, 其核心流程在其父類: TransportReplicationAction。 個(gè)人覺(jué)得這個(gè)名字起得不好，讓人以為是只會(huì)在副本上執(zhí)行相關(guān)功能的意思。

了解TransportReplicationAction之前，先說(shuō)一下delete api的執(zhí)行流程，就是劇透結(jié)果，再解析劇情。

從ES中刪除一個(gè)文檔的過(guò)程如下: 先從主分片中執(zhí)行刪除操作，再在所有的副本分片上執(zhí)行刪除操作。 所以核心流程分三步:

s1: 從請(qǐng)求節(jié)點(diǎn)路由到主分片節(jié)點(diǎn)。

s2: 在主分片節(jié)點(diǎn)執(zhí)行刪除操作。

s3: 在所有的副本分片上執(zhí)行刪除操作。

按如上所述, 在TransportReplicationAction類中，對(duì)應(yīng)著三個(gè)子類:

這個(gè)結(jié)構(gòu)是通用的，就像模板一樣。 這個(gè)類有個(gè)注釋，解釋了類的運(yùn)行流程:

/**
 * Base class for requests that should be executed on a primary copy followed by replica copies.
 * Subclasses can resolve the target shard and provide implementation for primary and replica operations.
 *
 * The action samples cluster state on the receiving node to reroute to node with primary copy and on the
 * primary node to validate request before primary operation followed by sampling state again for resolving
 * nodes with replica copies to perform replication.
 */

解釋起來(lái)有如下的關(guān)鍵幾點(diǎn):

1. 基于該類的請(qǐng)求先會(huì)在primary shard執(zhí)行，然后在replica shard執(zhí)行。
2. 具體執(zhí)行的操作由子類實(shí)現(xiàn)，比如`TransportDeleteAction`就實(shí)現(xiàn)了刪除的操作。
3. 每個(gè)節(jié)點(diǎn)在執(zhí)行相關(guān)的操作前需要基于cluster state對(duì)請(qǐng)求參數(shù)進(jìn)行驗(yàn)證。這個(gè)驗(yàn)證對(duì)應(yīng)的方法就是`resolveRequest`

基于這個(gè)流程，可以看出，刪除操作還是比較重量級(jí)的， 副本越多，刪除的代價(jià)就越大。

由于ES每個(gè)節(jié)點(diǎn)代碼都是一樣的，所以默認(rèn)情況下每個(gè)節(jié)點(diǎn)的可扮演的角色是自由切換的。 這里主要是在研讀transportService.sendRequest()方法時(shí)的一個(gè)小竅門。 比如代碼:

        void performOnReplica(final ShardRouting shard) {
            // if we don't have that node, it means that it might have failed and will be created again, in
            // this case, we don't have to do the operation, and just let it failover
            final String nodeId = shard.currentNodeId();

            ...

            final DiscoveryNode node = nodes.get(nodeId);
            transportService.sendRequest(node, transportReplicaAction, ... ){
                ...
            }
        }

這里transportService.sendRequest()后，接受的邏輯在哪里呢？

  transportService.registerRequestHandler(actionName, request, ThreadPool.Names.SAME, new OperationTransportHandler());
  transportService.registerRequestHandler(transportPrimaryAction, request, executor, new PrimaryOperationTransportHandler());
 // we must never reject on because of thread pool capacity on replicas
  transportService.registerRequestHandler(transportReplicaAction, replicaRequest, executor, true, true, new ReplicaOperationTransportHandler());

也就是說(shuō)transportService.sendRequest()的第二個(gè)參數(shù)action和transportService.registerRequestHandler()的第一個(gè)參數(shù)action是一一對(duì)應(yīng)的。
遇到transportService.sendRequest()直接通過(guò)action參數(shù)找到對(duì)應(yīng)的Handler即可。比如PrimaryOperationTransportHandler就是用于接收ReroutePhase().run()方法中發(fā)送出去的請(qǐng)求。

回到TransportDeleteAction, 來(lái)理解ES刪除的邏輯，整個(gè)類就只需要理解2個(gè)方法:

# 在primary shard執(zhí)行的刪除邏輯
shardOperationOnPrimary()

# 在replica shard執(zhí)行的刪除邏輯
executeDeleteRequestOnReplica()

這里面就是刪除的具體邏輯，Engine相關(guān)的內(nèi)容后續(xù)再深入。

關(guān)于刪除，ES提供的是delete by id的思路。 早期ES是支持通過(guò)query批量刪除的，后來(lái)覺(jué)得這個(gè)功能太過(guò)危險(xiǎn)，就將delete by query做成了Plugin, 由用戶自行安裝插件后才能使用。 關(guān)于ES批量刪除的思路，可以參考delete by query插件的源碼，大體思路是通過(guò)scroll query 按條件查詢出doc id, 然后使用client.bulk()進(jìn)行刪除。

最后，由于TransportReplicationAction是個(gè)比較通用的模式，所以ES其他的功能也是基于這個(gè)模式的， 比如: TransportIndexAction。