1.写一致性原理

我们在发送任何一个增删改操作的时候，比如说 put /index/type/id,都可以带上一个consistency参数，指明我们想要的写一致性是什么。
PUT /index/type/id?consistency=quorum
one: 要求我们这个写操作，只要primary shard是active活跃可用的，就可以执行写操作
all：要求我们这个写操作，必须所有的primary shard都是活跃的，才能执行写操作
quorum：也是consistency默认值，要求所有的shard中，必须是大部分的shard都是活跃的，才能执行写操作

2.quorum机制

number_of_replicas: 是数据备份数，如果只有一台机器，设置为0
number_of_shards: 是数据分片数，默认为5，有时候设置为3
写之前必须确保大多数shard都可用，int((primary + number_of_replica)/2) + 1,当number_of_replica>1时才生效
个人觉得计算公式如下：
int((primary + primary number_of_replica)/2) + 1
举例说明：
3个primary shard，number_of_replica=1,总共有3+31 = 6个shard
quorum = （int(3+1)/2 ） + 1 = 3 ，所以要求6个shard中必须至少有3个shard是active状态的时候，才能执行写操作。

3.如果节点数小于quorum数量，可能导致quorum不齐全，进而导致无法执行任何写操作

举例：3个primary shard，replica=1，要求至少有3个shard是active状态的，3个shard按照之前的学习，shard&replica机制，必须在不同的节点上，如果说只有2台机器的话，是不是有可能出现，3个shard都没法分配齐全，此时就可能会出现写操作无法执行的情况。
es提供了一种特殊的场景，就是说当number_of_replicas>1时才生效，因为假如说，你就一个primary shard，replica=1，此时就2个shard
(1+1)/2+1 = 2，要求必须有2个shard是活跃的，但是可能就1个node，此时就1个shard是活跃的，如果你不特殊处理的话，单只我们的单节点集群就无法工作
个人理解：
首先 number_of_replica>1时才生效，那么案例中 number_of_replica = 1 的案例是否合理？
其次，如果 number_of_replica = 2, 根据上面的公式计算： quorum = (int(3+2)/2) + 1 = 3, 而 shard 数量有 9，无法满足大部分 shard active 的条件？
补充说明：
1个primary shard，replica=3，quorum=((1+3)/2)+1 = 3，要求1个primary shard + 3个replica shard = 4个shard，其中必须有3个shard是要处于active状态的，如果这个时候只有2台机器的话，会出现什么情况呢？
此时P0，R0-0，R0-1，R0-2，并且只有两个node节点时，因为primary shard和replica shard不能在一个节点上，所以最多只能分配两个shard到两个node上，
此时的shard数小于quorum的要求，所以不满足条件，es默认等待，等待新的shard增加，直到timeout

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

如果quorum不齐全，es默认等待，期望活跃的shard数量可以增加，最后实在不行，就会timeout
我们其实可以在写操作的时候，加一个timeout参数，比如说 put /index/type/id?timeout=30,这个参数就是说自己去设定quorum不齐全的时候，es的timeout时长，可以缩短，也可以增长。timeout的单位默认为ms，如果希望为s，那么写成?timeout=30s