ES源碼學習之--Get API的實現邏輯

Github上es項目講述其易用性時，用來舉例說明ES開箱即用的特性，用的就是Get API。片斷摘取以下:

-- 添加文檔
curl -XPUT 'http://localhost:9200/twitter/doc/1?pretty' -H 'Content-Type: application/json' -d '
{
    "user": "kimchy",
    "post_date": "2009-11-15×××3:12:00",
    "message": "Trying out Elasticsearch, so far so good?"
}'

-- 讀取文檔
curl -XGET 'http://localhost:9200/twitter/doc/1?pretty=true'

Get API一般的用途有2點:
1 檢測添加的文檔跟預期是否相符, 這在問題排查時超級實用。

2 根據id獲取整個文檔明細， 用於搜索的fetch階段。

研究ES的內部機制， Get API是一個極佳的切入點。經過Get API， 能夠了解到的知識點有：

a. ES的rest api實現方式。

b. ES的文檔路由方式。

c. ES的RPC實現機制。

d. ES的translog.

e. ES如何使用lucene 的IndexSearcher。

f. ES如何根據id獲取到lucene的doc_id。

g. ES如何根據lucene的doc_id 獲取文檔明細。

.......

研究ES的內部機制，有助於釋放ES的洪荒之力。例如：根據業務開發ES的plugin時，其內部流程是很好的借鑑。 內部細節瞭解越多，越不容易踩坑。

GET API的核心流程以下:

s1: 接收客戶端請求

看到controller.registerHandler()方法，很容易就聯想到http的請求

public class RestGetAction extends BaseRestHandler {

     @Inject
    public RestGetAction(Settings settings, RestController controller, Client client) {
        super(settings, controller, client);
        controller.registerHandler(GET, "/{index}/{type}/{id}", this);
    } 

    @Override
    public void handleRequest(final RestRequest request, final RestChannel channel, final Client client) {
           ...
        client.get(getRequest, new RestBuilderListener<GetResponse>(channel) {
            ...
        });
    }
}

s2: 在當前節點執行該請求

public class NodeClient extends AbstractClient {
    ...
    @Override
    public <Request extends ActionRequest, Response extends ActionResponse, 
            RequestBuilder extends ActionRequestBuilder<Request, Response, RequestBuilder>> 
       void doExecute(Action<Request, Response, RequestBuilder> action, Request request, ActionListener<Response> listener) {
        TransportAction<Request, Response> transportAction = actions.get(action);
        ...
        transportAction.execute(request, listener);
    }
}

這裏隱含了一個actions的映射表, 以下:
public class ActionModule extends AbstractModule {
    ...

    @Override
    protected void configure() {
        ...
        registerAction(GetAction.INSTANCE, TransportGetAction.class);
        ...
    }
}

s3: 定位文檔所在分片

文檔的定位思路很簡單， 默認根據文檔id, 用hash函數計算出文檔的分片ShardId, 經過分片ShardId定位出NodeId。 
ES內部維護了一張相似路由表的對象，類名就是RoutingTable. 經過RoutingTable, 能夠根據索引名稱找到全部的分片；能夠經過分片Id找到分片對應的集羣Node. 
關於文檔的定位，從應用的角度有兩個知識點：routing和preference

public class TransportGetAction extends TransportSingleShardAction<GetRequest, GetResponse> {

    ...

    @Override
    protected ShardIterator shards(ClusterState state, InternalRequest request) {
        return clusterService.operationRouting()
                .getShards(clusterService.state(), request.concreteIndex(), request.request().type(), request.request().id(), request.request().routing(), request.request().preference());
    }
}

s4: 將請求轉發到分片所在的節點

請求的分發，涉及到ES的RPC通訊。上一步定位到NodeId, 將請求發送到該NodeId便可。
因爲ES的每一個Node代碼都是同樣的， 所以每一個Node既承擔Server也承擔Client的責任，這跟其餘的RPC框架有所不一樣。
核心方法是transportService.sendRequest() 和 messageReceived()。 

public abstract class TransportSingleShardAction<Request extends SingleShardRequest, Response extends ActionResponse> extends TransportAction<Request, Response> {

    class AsyncSingleAction {

        public void start() {
                transportService.sendRequest(clusterService.localNode(), transportShardAction, internalRequest.request(), new BaseTransportResponseHandler<Response>() {
                    ...     
                });
        }

    }

    private class ShardTransportHandler extends TransportRequestHandler<Request> {

        @Override
        public void messageReceived(final Request request, final TransportChannel channel) throws Exception {

            ...
            Response response = shardOperation(request, request.internalShardId);
            channel.sendResponse(response);
        }
    }

}

s5: 經過id讀取索引文件獲取該id對應的文檔信息

這裏分兩個階段:
step1: 將type和id合併成一個字段，從lucene的倒排索引中定位lucene的doc_id

step2: 根據doc_id從正向信息中獲取明細。

public final class ShardGetService extends AbstractIndexShardComponent {

      ...

    private GetResult innerGet(String type, String id, String[] gFields, boolean realtime, long version, VersionType versionType, FetchSourceContext fetchSourceContext, boolean ignoreErrorsOnGeneratedFields) {
        fetchSourceContext = normalizeFetchSourceContent(fetchSourceContext, gFields);
                ...
                get = indexShard.get(new Engine.Get(realtime, new Term(UidFieldMapper.NAME, Uid.createUidAsBytes(typeX, id)))
                        .version(version).versionType(versionType));

                ...
               innerGetLoadFromStoredFields(type, id, gFields, fetchSourceContext, get, docMapper, ignoreErrorsOnGeneratedFields); 
        }
    }

(注: 若是是realtime=true, 則先從translog中讀取source, 沒有讀取到才從索引中讀取)

s5涉及到Lucene的內部實現， 這裏不展開贅述。

最後總結一下:

Get API是ES內部打通了整個流程的功能點。從功能上看，它足夠簡單；從實現上看，他又串聯了ES的主流程，以它爲切入口，不會像展現You Know, for Search的RestMainAction那樣浮於表面；又不會像實現搜索的接口那樣龐雜難懂。