es的preference参数使用问题

我把问题中的“读”，理解成search操作，因为看官方文档：preference是针对search API的参数，GET 是 real time的(GET 也有preference参数)。如果你的数据是 bulk indexing 到ES后需要立即搜索可见，那还得受 refresh_interval 参数的影响，那对这样的数据谈读写分离，有点不靠谱：ES6.8 search-request-preference

The _primary, _primary_first, _replica and _replica_first are deprecated as their use is not recommended. They do not help to avoid inconsistent results that arise from the use of shards that have different refresh states, and Elasticsearch uses synchronous replication so the primary does not in general hold fresher data than its replicas.

对于写而言，比如一次 bulk indexing 10w 条数据，base64自动生成docid，然后murmru3 hash到各个主分片上，由于各个主分片分布在不同的节点上(比如5个主分片1个副本的索引)，那么对于10w条数据而言，写压力是分散了的。
对于读(search)而言，由于ES遵从scatter/gather模型，针对一个索引的search请求要分发给所有的分片，这时可以把search操作转发到主分片所在的节点，也可以转发到副本分片所在的节点，而这就是preference参数所起作用的地方了。Basic read model

Select an active copy of each relevant shard, from the shard replication group. This can be either the primary or a replica. By default, Elasticsearch will simply round robin between the shard copies.

举例：
搜索一个关键词，命中这个关键词的segment加载到内存，多搜索几次，file system cache就会有缓存，如果是 filter context search，那还有 node query cache ，如果这样的请求都转发到 某个固定的shard上，比如preference=local，那么就能直接命中这个shard所在的节点的各种缓存了，而如果search请求随机指定分片发送，那么请求发送到不同的节点上，那么就不能充分利用缓存了。参考这个链接：preference-cache-optimization
 
而至于你说的“副本会收到数据同步的流量”，这只是ES的数据副本模型(参考前面链接)，indexing 先到primary shard，然后转发到insync replicas，最后返回ACK给client。这与kafka borker保存producer发送的消息 过程是类似的。如果把读写分离理解成读操作、写操作 能够 转发到不同的节点上执行，可能会好理解一点吧。
 
 

我建议你看一下我的文章：Elasticsearch：运用shard filtering来控制索引分配给哪个节点