es5之前

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

我们在发送任何一个增删改操作的时候，比如 PUT /index/indextype/id ,都可以带上一个consistency参数，指明我们想要的写一致性是什么？

  1. PUT /index/indextype/id?consistency=quorum
  • one：要求我们这个写操作，只要有一个primary shard是active状态，就可以执行。
  • all：要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作。
  • quorum：默认值，要求所有的shard中，必须是法定数的shard都是活跃的,可用的，才可以执行这个写操作

    quorum机制

    写之前必须确保法定数shard可用

  1. 公式：

    1. int((primary shard + number_of_replicas) / 2) + 1 
    2. 当number_of_replicas > 1时才生效。 
    3. 3 primary shard + 1 = 6 shard ---> 3

  2. 举例

比如： 1个primary shard，3个replica。那么 quorum=((1 + 3) / 2) + 1 = 3，要求3个primary shard+1个replica shard=4个shard中必须有3个shard 是要处于active状态，若这时候只有两台机器的话，会出现什么情况？
image.png

timeout机制

quorum不齐全时，会wait（等待）1分钟

  1. 默认1分钟，可以设置timeout手动去调，默认单位毫秒。 
  2. 等待期间，期望活跃的shard数量可以增加，最后无法满足shard数量就会timeout，我们其实可以在写操 作的时候，加一个timeout参数，比如说PUT /index/_doc/id?timeout=30s，这个就是说自己去设定 quorum不齐全的时候，ES的timeout时长。默认是毫秒，加个s代表秒

ElasticSearch5.0以及以后的版本

从ES5.0后，原先执行put 带 consistency=all/quorum 参数的，都报错了，提示语法错误。

原因是consistency检查是在Put之前做的。然而，虽然检查的时候，shard满足quorum，但是真正从 primary shard写到replica之前，仍会出现shard挂掉，但Update Api会返回succeed。

因此，这个检查并不能保证replica成功写入，甚至这个primary shard是否能成功写入也未必能保证。 因此，修改了语法，用了下面的 wait_for_active_shards，因为这个更能清楚表述，而没有歧义。

  1. PUT /test_index/_doc/1?wait_for_active_shards=2&timeout=10s 
  2. { 
  3.     "name":"xiao mi" 
  4. }