Elasticsearch和CAP定理

Question

Elasticsearch是一个分布式系统。根据CAP定理，它可以满足任意2/3的性质。哪一个在Elasticsearch中被破坏了？

Answer 1

我强烈反对Harshit，Elasticsearch在可用性方面的妥协，因为他还提到由于碎片不可用而返回的请求很少是错误的。

ES保证一致性--因为数据读/写总是一致的。保证ES挑战者对分区的容忍--如果任何被分区的节点在一段时间后被重新加入到集群中，它就能够将丢失的数据恢复到当前状态。

此外，没有一个分布式系统放弃了划分容限，因为没有PT分布式系统的保证是不存在的。

Answer 2

答案并不那么简单。这取决于系统的配置方式和您想要如何使用它。我将试着详细讨论这些细节。

ElasticSearch中的配准

1. --每个索引都用碎片进行分区，这意味着每个碎片中的数据与其他碎片相互排斥。每个碎片还具有多个Lucence索引，这些索引不在此答案的范围内。
2. 每个碎片可以有一个副本运行(大多数设置都有)，如果发生故障，则可以将副本提升为主服务器。让我们调用一个具有主工作并且可以从我们的应用服务器作为活动碎片访问的ES节点的碎片。因此，具有的碎片(在主部件中不复制且不可到达)被认为是失败的碎片。(例如:如果错误地说“所有碎片都失败了”，就意味着在该索引中没有一个available)
3. ES具有多个主分区的特性(发散碎片)。这不是一个好情况，因为我们都失去了读写consistencies.

。

在发生网络分区的情况下，会发生什么情况：

1. Reads

1. By default reads will continue to happen on shards that are active. Thus, the data from failed shards will be excluded from our search queries. In this context, we consider the system to be **AP**. However, the situation is temporary and does not require manual effort to synchronize shard when the cluster is connected again.
2. By setting a search option `allow_partial_search_results` [1] to `false`, we can force the system to error when some of the shards have failed, guaranteeing consistent results. In this context, we consider the system to be **CP**.
3. In case no primaries are reachable from the node(s) that our application server is connecting to, the system will completely fail. Even if we say that our partition tolerance has failed, we also see that availability has taken a hit. This situation can be called be just **C** or **CP**
4. There can be cases where the team has to anyhow bring up the shards and their out of sync replica(s) were reachable. So they decide to make it a primary (manually). Note that there can be some un-synced data resulting in divergent shards. This results in the **AP** situation. Consistency will be hard to restore when the situation normalizes (sync shards manually)

1. Writes

1. Only if all shards fail, writes will stop working. But even if one shard is active writes will work and are consistent (by default). This will be **CP**
2. However, we can set option `index-wait-for-active-shards` [2] as `all` to ensure writes only happen when all shards in the index are active. I only see a little advantage of the flag, which would be to keep all shards balanced at any cost. This will be still **CP** (but lesser availability than the previous case)
3. Like in the last read network partition case, if we make un-synced replicas as primary (manually) there can be some data loss and divergent shards. The situation will be **AP** here and consistency will be hard to restore when the situation normalizes (sync shards manually)

基于上述，您可以做出更明智的决策，并根据您的需求对ElasticSearch进行调整。

参考文献：

1. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html
2. https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#index-wait-for-active-shards

Answer 3

上限定理指出，分布式系统最多可以有以下两种情况：

1. Consistency.
2. Availability.
3. Partition公差.

Elasticsearch放弃“划分容限”

原因：这意味着如果节点创建失败，集群健康将变成红色，并且不会对新创建的索引进行操作。

它将放弃"Availability"，因为每个Elasticsearch查询都将从集群返回一个响应，即true (结果)/ false (错误)。

它也不会让"Consistency"放弃，而不是。如果它放弃了一致性，那么就不会有任何文档版本控制和索引恢复。

你在这里读到了更多：https://discuss.elastic.co/t/elasticsearch-and-the-cap-theorem/15102/8