42 lines
3.9 KiB
Markdown
42 lines
3.9 KiB
Markdown
### 路由一份文档到分片
|
||
一份文档在哪个分片，由以下公式决定
|
||
```
|
||
shard = hash(routing) % number_of_primary_shards
|
||
```
|
||
|
||
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置
|
||
所以规定：创建索引的时候，主分片的数量不能变，不然之前路由的值都会无效，文档再也找不到了
|
||
所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。
|
||
|
||
### 写操作过程（创建文档，索引，删除等）
|
||
```
|
||
1、客户端向 某个节点（node） [协调节点]发送新建、索引或者删除请求。
|
||
2、节点[协调节点]使用文档的 _id 确定文档属于哪个分片 。请求会被转发到该分片的主分片所在的节点（node） 上。
|
||
3、该节点（node）在主分片上面执行请求。如果成功了，它将请求并行转发到 该主分片的其他副本分片上。一旦所有的副本分片都报告成功, 该节点将向协调节点报告成功，协调节点向客户端报告成功。
|
||
```
|
||
|
||
### 其他可能以数据安全为代价提升性能的参数
|
||
#### consistency
|
||
```
|
||
consistency，即一致性。在默认设置下，即使仅仅是在试图执行一个_写_操作之前，主分片都会要求 必须要有 规定数量(quorum)（或者换种说法，也即必须要有大多数）的分片副本处于活跃可用状态，才会去执行_写_操作(其中分片副本可以是主分片或者副本分片)。这是为了避免在发生网络分区故障（network partition）的时候进行_写_操作，进而导致数据不一致。_规定数量_即：
|
||
|
||
int( (primary + number_of_replicas) / 2 ) + 1
|
||
consistency 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操作）,all（必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_操作。
|
||
|
||
注意，规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片，那规定数量的计算结果即：
|
||
|
||
int( (primary + 3 replicas) / 2 ) + 1 = 3
|
||
如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数量，也因此您将无法索引和删除任何文档。
|
||
```
|
||
#### timeout
|
||
```
|
||
如果没有足够的副本分片会发生什么？ Elasticsearch会等待，希望更多的分片出现。默认情况下，它最多等待1分钟。 如果你需要，你可以使用 timeout 参数 使它更早终止： 100 100毫秒，30s 是30秒。
|
||
```
|
||
|
||
### 局部更新
|
||
```
|
||
1、客户端向某个节点[协调节点]发送更新请求。
|
||
2、该节点[协调节点]将请求转发到该文档的主分片所在节点。
|
||
3、该节点从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。 如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃。
|
||
4、如果 主分片所在节点成功地更新文档，它将新版本的文档并行转发到副本分片，重新建立索引。 一旦所有副本分片都返回成功， 主分片所在的节点向协调节点也返回成功，协调节点向客户端返回成功。
|
||
```
|