ES 对索引进行操作，比如增加文档等，是在主分片和副分片同时操作吗？还是异步写入的？返回码是在什么时候返回？

https://www.elastic.co/guide/c ... .html

在ES5.0以前，通过consistency策略控制：按照ES的主副同步策略，主分片本地索引完成后，会将请求forward到副本分片，默认情况下超过半数副本回复后，主分片才响应client端操作成功。
在5.0以后，这个参数已经被wait_for_active_shards参数(默认值1)取代，即默认情况下只要主分片就可以完成写操作，否则阻塞至超时或者满足条件。
在主完成本地索引后，会forward所有 被称作in-sync copies 的列表里的分片，直到列表所有分片响应成功，才响应client。如果部分失败，则会通知master，将故障分片从in-sync copies 列表里剔除，主分片响应client，与此同时，master会分配一个新的分片来接替故障的分片。
in-sync copies 的内容可以通过API

GET /_cluster/state?filter_path=metadata.indices.your-indexname.in_sync_allocations.*,routing_table.indices.your-indexname.*

查看。
可以细读一下官方文档https://www.elastic.co/guide/e ... tions。
 

这个问题我一直有个疑问，我用的es2.x版本，官网的文档也是基于2.x的版本，文档的原文这样写的：
Node 3 executes the request on the primary shard. If it is successful, it forwards the request in parallel to the replica shards on Node 1 and Node 2. Once all of the replica shards report success, Node 3 reports success to the coordinating node, which reports success to the client.
简单来说就是主分片写完，在同步到副本分片上，等待所有的分片写完才返回成功（Once all of the replica shards report success），即数据写入，主副本之间采用的是同步写入。
第一个疑问：
这个操作时对一批写入数据而言，还是一条数据而言，个人理解应该是该次写入请求的写入数据量，那么如果我一次写入数据很大，要等主分片和副本分片写完，再返回响应，这个等待时间是否太久；
第二个疑问：
因为es有个translog，就是为了保证数据写入安全，在hbase中，只要数据写入并在WAL日志（类似translog保证数据写入安全的日志文件）记录，即返回数据成功，并没有像es文档所说的等待所有分片写成功再返回；
第三个疑问：
es通过consistency参数控制数据的一致性，说白了就是在什么样情况下允许写入，在5.x中可以看到
"index.write.wait_for_active_shards"默认值为1

    /**

     * The number of active shard copies to check for before proceeding with a write operation.

     */

    public static final Setting<ActiveShardCount> SETTING_WAIT_FOR_ACTIVE_SHARDS =

        new Setting<>("index.write.wait_for_active_shards",

                      "1",

                      ActiveShardCount::parseString,

                      Setting.Property.Dynamic,

                      Setting.Property.IndexScope);

像yayg2008，所说要写入到in-sync copies 的列表里的分片，直到列表所有分片响应成功，才响应client。这样无法就是改变了能否写入的条件（即主分片处于活跃状态写入就可以），但是数据的主副本一致性还是采用的是同步方式，这样是不是效率仍然没有提高？
一起讨论研究研究
 

这里顺便把官网的原话贴出来：
The index operation only returns after all active shards within the replication group have indexed the document (sync replication).