ES學習筆記之--delete api的實現流程

ES的delete api使用非常簡單。

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

前面學習了get api的主要流程，這里探索一下delete api的實現原理。 優先選擇delete api而非index api, 主要是覺得刪除貌似更容易， 選擇delete api學習曲線應該比較平緩。

ES相關功能Action的命名很統一， 比如get api, 對應實現類的名稱為TransportGetAction, delete api對應實現類的名稱也是依樣畫葫蘆: TransportDeleteAction。

但是學習TransportDeleteAction, 其核心流程在其父類: TransportReplicationAction。 個人覺得這個名字起得不好，讓人以為是只會在副本上執行相關功能的意思。

了解TransportReplicationAction之前，先說一下delete api的執行流程，就是劇透結果，再解析劇情。

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

s1: 從請求節點路由到主分片節點。

s2: 在主分片節點執行刪除操作。

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

按如上所述, 在TransportReplicationAction類中，對應著三個子類:

這個結構是通用的，就像模板一樣。 這個類有個注釋，解釋了類的運行流程:

/**
 * 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.
 */

解釋起來有如下的關鍵幾點:

1. 基于該類的請求先會在primary shard執行，然后在replica shard執行。
2. 具體執行的操作由子類實現，比如`TransportDeleteAction`就實現了刪除的操作。
3. 每個節點在執行相關的操作前需要基于cluster state對請求參數進行驗證。這個驗證對應的方法就是`resolveRequest`

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

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

        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());

也就是說transportService.sendRequest()的第二個參數action和transportService.registerRequestHandler()的第一個參數action是一一對應的。
遇到transportService.sendRequest()直接通過action參數找到對應的Handler即可。比如PrimaryOperationTransportHandler就是用于接收ReroutePhase().run()方法中發送出去的請求。

回到TransportDeleteAction, 來理解ES刪除的邏輯，整個類就只需要理解2個方法:

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

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

這里面就是刪除的具體邏輯，Engine相關的內容后續再深入。

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

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