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
類中,對應着三個子類:
class name | 功能 |
---|---|
ReroutePhase | 將請求路由到primary 分片所在的節點 |
PrimaryPhase | 在主分片執行任務 |
ReplicationPhase | 在所有的replica分片上執行任務 |
這個結構是通用的,就像模板一樣。 這個類有個註釋,解釋了類的運行流程:
/**
* 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
。