@Elasticsearch之深度应用及原理剖析--分布式数据一致性机制

title: ElasticSearch之深度应用及原理剖析author: Xonitags:

• 搜索引擎
• Elasticsearchcategories:
• 搜索引擎
• Elasticsearchabbrlink: 5a1f6e0b

第4节 分布式数据一致性如何保证？

quorum及timeout机制的原理在分布式环境下，一致性指的是多个数据副本是否能保持一致的特性。在一致性的条件下，系统在执行数据更新操作之后能够从一致性状态转移到另一个一致性状态。对系统的一个数据更新成功之后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。

4.1 ES5.0以前的一致性

consistency，one（primary shard），all（all shard），quorum（default）我们在发送任何一个增删改操作的时候，比如 PUT /index/indextype/id ，都可以带上一个consistency参数，指明我们想要的写一致性是什么？PUT /index/indextype/id?**consistency=quorum**

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

4.2 quorum机制

写之前必须确保法定数shard可用（1）公式：

int((primary shard + number_of_replicas) / 2) + 1
当number_of_replicas > 1时才生效。 
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状态，若这时候只有两台机器的话，会出现什么情况？

4.3 timeout机制

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

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

4.4 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(等待获得分片数)，因为这个更能清楚表述，而没有歧义。例子：

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