elasticsearch - Elasticsearch 和 CAP 定理

Question

Elasticsearch 是一个分布式系统。根据 CAP 定理，它可以满足 3 个属性中的任意 2 个。哪一个在 Elasticsearch 中受到损害？

Answer 1

答案并不那么简单。这取决于系统的配置方式以及您希望如何使用它。我将尝试详细介绍。

ElasticSearch 中的分区

1. 每个索引都划分为分片，这意味着每个分片中的数据与其他分片互斥。每个分片还具有多个 Lucence 索引，这些索引不在此答案的范围内。
2. 每个分片都可以运行一个副本（大多数设置都有），并且在发生故障时，可以将副本提升为主分片。让我们称一个分片有一个主要的工作并且可以从我们的应用程序服务器作为一个活动分片命中的 ES 节点访问。因此，主分片中没有副本且不可访问的分片被视为失败分片。（例如：“所有分片失败”的错误表示该索引中没有可用的主索引）
3. ES 有一个特性，即拥有多个主分片（发散分片）。这不是一个好的情况，因为我们失去了读/写的一致性。

如果发生网络分区，将会发生什么：

1. 阅读：

   1. 默认情况下，读取将继续发生在活动的分片上。因此，来自失败分片的数据将从我们的搜索查询中排除。在这种情况下，我们认为系统是AP。但是，这种情况是暂时的，不需要在集群再次连接时手动同步 shard。
   2. 通过将搜索选项allow_partial_search_results[1] 设置为false，我们可以在某些分片失败时强制系统出错，从而保证一致的结果。在这种情况下，我们认为系统是CP。
   3. 如果无法从我们的应用程序服务器连接的节点访问主节点，系统将完全失败。即使我们说我们的分区容错失败了，我们也看到可用性受到了打击。这种情况可以称为只是C或CP
   4. 在某些情况下，团队无论如何都必须调出分片，并且可以访问它们的不同步副本。因此，他们决定将其设为主要（手动）。请注意，可能会有一些未同步的数据导致分片不同。这导致了AP的情况。当情况正常化时，一致性将难以恢复（手动同步分片）

2. 写

   1. 只有当所有分片都失败时，写入才会停止工作。但即使一个分片处于活动状态，写入也将起作用并且是一致的（默认情况下）。这将是CP
   2. 但是，我们可以设置选项index-wait-for-active-shards[2]all以确保仅在索引中的所有分片都处于活动状态时才发生写入。我只看到了这个标志的一点优势，那就是不惜一切代价保持所有分片的平衡。这仍将是CP（但可用性低于前一个案例）
   3. 就像上次读取网络分区的情况一样，如果我们（手动）将未同步的副本作为主要副本，则可能会丢失一些数据和分片。这里的情况将是AP，当情况正常时，一致性将难以恢复（手动同步分片）

基于上述，您可以做出更明智的决定，并根据您的要求调整 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 2

我强烈不同意 Harshit，Elasticsearch 在可用性方面的妥协，因为他还提到由于分片不可用，很少有请求返回错误。

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

而且，没有分布式系统会放弃Partition Tolerance，因为没有PT保证的分布式系统是不可能存在的。

Answer 3

CAP 定理指出，分布式系统最多可以有以下两个：

1. 一致性。
2. 可用性。
3. 分区容差。

Elasticsearch 放弃了“Partition Tolerance”

原因：表示如果创建节点失败，集群健康会变成红色，不会继续对新创建的索引进行操作。

它不会放弃“可用性”，因为每个 Elasticsearch 查询都会从集群返回true (results) / false (error)的响应。

它也不会放弃“一致性”。如果它放弃一致性，那么将不会有任何文档版本控制和索引恢复。

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