Elasticsearch——document相关原理

1. document数据路由原理

1.1 document路由到shard上是什么意思？

一个index的数据会被分为多片，每片都在一个shard中。因此说，一个document，只能存在于一个shard中。

当客户端建立document的时候，es此时就须要决定说，这个document是放在这个index的哪一个shard上。

这个过程，就称之为document routing, 数据路由。
复制代码

1.2. 路由算法

shard = hash(routing) % number_of_primary_shards
举例说明：
- 一个index有3个primary shard，P0，P1，P2

- 每次增删改查一个document的时候，都会带过来一个routing number，默认就是这个document的_id（多是手动指定，也多是自动生成）
复制代码

routing = _id，假设_id=1 - 会将这个routing值，传入一个hash函数中，产出一个routing值的hash值，假设hash(routing) = 21 而后将hash函数产出的值对这个index的primary shard的数量求余数，21 % 3 = 0 就决定了，这个document就放在P0上。 - 决定一个document在哪一个shard上，最重要的一个值就是routing值，默认是_id，也能够手动指定，相同的routing值，每次过来，从hash函数中，产出的hash值必定是相同的

不管hash值是几，不管是什么数字，对number_of_primary_shards求余数，结果必定是在0~number_of_primary_shards-1之间这个范围内的。0,1,2。
复制代码

1.3 手动指定 routing id

• 默认的routing就是_id，也能够在发送请求的时候，手动指定一个routing value，好比说 put /index/type/id?routing=user_id
• 手动指定routing value是颇有用的，能够保证说，某一类document必定被路由到一个shard上去，那么在后续进行应用级别的负载均衡，以及提高批量读取的性能的时候，是颇有帮助的

1.4 primary shard 数量不可变的原理

• 根据路由算法中的例子，当document的_id为1时，计算出的结果为0，就是在P0 shard 上。

• 若是增长一个primary shard，变为4个，_id=1, 则计算出来的结果为 21 % 4 = 1，就去P1 shard 上找这条数据，结果就会找不到，间接致使数据丢失。

  

2. document增删改内部实现原理

首先，增删改操做只能有 primary shard 处理，不能由 replica sahrd处理。

具体步骤：

1. 客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）

2. coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）

3. 实际的node上的primary shard处理请求，而后将数据同步到replica node

4. coordinating node，若是发现primary node和全部replica node都搞定以后，就返回响应结果给客户端

   

3. document写一致性原理及quorum机制

3.1 consistency，one（primary shard），all（all shard），quorum（default）

咱们在发送任何一个增删改操做的时候，好比说put /index/type/id，均可以带上一个consistency参数，指明咱们想要的写一致性是什么？ put /index/type/id?consistency=quorum

• one：要求咱们这个写操做，只要有一个primary shard是active活跃可用的，就能够执行
• all：要求咱们这个写操做，必须全部的primary shard和replica shard都是活跃的，才能够执行这个写操做
• quorum：默认的值，要求全部的shard中，必须是大部分的shard都是活跃的，可用的，才能够执行这个写操做

3.2 quorum机制

• quorum机制，写以前必须确保大多数shard均可用，int( (primary + number_of_replicas) / 2 ) + 1，当number_of_replicas>1时才生效

  quroum = int( (primary + number_of_replicas) / 2 ) + 1
  复制代码

举个例子，3个primary shard，number_of_replicas=1，总共有3 + 3 * 1 = 6个shard， quorum = int( (3 + 1) / 2 ) + 1 = 3 因此，要求6个shard中至少有3个shard是active状态的，才能够执行这个写操做

• 若是节点数少于quorum数量，可能致使quorum不齐全，进而致使没法执行任何写操做

  此处有一个问题：

  es提供了一种特殊的处理场景，就是说当number_of_replicas>1时才生效，由于假如说，你就一个primary shard，replica=1，此时就2个shard (1 + 1)/2 + 1 = 2，要求必须有2个shard是活跃的，可是可能就1个node，此时就1个shard是活跃的，若是你不特殊处理的话，致使咱们的单节点集群就没法工做

  我在本身的机器上启动了一个节点，新建索引以下：

  PUT /quorum_test
  {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
  复制代码

  增长一条数据，成功了：

  PUT /quorum_test/type/1
  {
    "field1": "test"
  }
  返回：
  {
    "_index": "quorum_test",
    "_type": "type",
    "_id": "1",
    "_version": 1,
    "result": "created",
    "_shards": {
      "total": 2,
      "successful": 1,
      "failed": 0
    },
    "created": true
  }
  复制代码

  按照上面说的应该失败才对，不知道为何？

• quorum不齐全时，wait，默认1分钟，timeout，100，30s

  等待期间，指望活跃的shard数量能够增长，最后实在不行，就会timeout 咱们其实能够在写操做的时候，加一个timeout参数，好比说put /index/type/id?timeout=30，这个就是说本身去设定quorum不齐全的时候，es的timeout时长，能够缩短，也能够增加

4. document 查询原理

对于读请求，不必定将请求转发到primary shard上，也能够转发到replica shard上去。

具体步骤：

1. 客户端发送请求到任意一个node，成为coordinate node

2. coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其全部replica中随机选择一个，让读请求负载均衡

3. 接收请求的node返回document给coordinate node

4. coordinate node返回document给客户端

5. 特殊状况：document若是还在创建索引过程当中，可能只有primary shard有，任何一个replica shard都没有，此时可能会致使没法读取到document，可是document完成索引创建以后，primary shard和replica shard就都有了.