# ES弹性状态

ES弹性状态

以下是一篇官方博客的机翻，Engineering写于2014年4月27日。核心思想主要是介绍：

1. es为什么选择弹性——重建数据索引，数据不丢失。
2. 如何保障弹性——测试工程：随机测试和破坏性测试。测试重点是复现问题，这个过程提升了复现问题的能力。
3. 为了解决脑裂的问题，做了一个模拟传输，来复现问题。
   说实话，没啥干活，以为会讲算法和数据结构。

ES弹性状态

https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html

官方也说这个特别复杂，尽可能在处理边界情况。如果要跟踪这个过程，具体可以查看github

• ES弹性的issue
• ES弹性的思维过程

第一个问题是：为什么我们要在ES里关心弹性。不就是个搜索系统，一个简单的单主可信多镜像的数据源？你确定你经常会重建数据索引？

实话说，确实是。在弹性搜索之外，许多系统都有“唯一的真相来源”。如果你的SSoT是另一种数据存储、S3或者HDFS，你总是会重建数据索引。但是，事实上，你能重建数据索引，并不意味着我们为你的确做了这件事而高兴。我们又很多es存储p级数据的用户，重建索引花费了令人无法接受的大量时间，我们努力确保es不丢数据。

一个面向保持数据安全的主要问题是snapshot/restore API的增加。虽然它可能在之前有备份了es，但是这会令人烦躁且低效。有了快照/还原中可用的增量备份，您现在可以恢复数据，即使您的集群遭受了巨大的故障，无论是硬件故障还是用户引起的故障（请考虑DELETE/* ）。但是重新存储仍然需要花些时间。我们也想确保你运行中的集群是弹性的并且永不丢失数据。

我们如何介绍es弹性方便的内容呐？我们的处理有些简单。我们通过修复哪些issue是基于很可能发生的，修复范围有多广来判断。

如果是lucene或者es的核心，我们会尽可能快地修复。

我们如何保障系统是弹性的？有两个关键的因素。首先是我们自己的测试基础框架。有一件令人惊喜的事情发生在lucene上，帮助构建一个超级弹性，那就是随机测试。

把随机测试看作是一种“可预测的非理性”的测试基础设施。测试通常会停滞在稳定状态，而随机测试允许你使你的测试基础设施成为一个活的有机体，继续有效地“可预测的非理性”。

测试基础设施的另一部分是Simon让我们大家亲切地称之为“邪恶的测试”。这些不是混乱的猴子测试，而是疯狂的酸测试！例如，Lucene现在有一个目录（实际上是一个文件系统），用来模拟执行fsync调用时出现故障的硬件。

任何密切关注Elasticsearch的人都可能已经注意到Simon和我们团队中的其他人为将这个令人惊叹的随机测试基础设施引入Elasticsearch所做的工作。今天，Elasticsearch中的每一次测试运行都与前一次有着显著的不同（很好的方式），将我们的代码暴露在一系列我们人类不会考虑的条件下。当出现故障时，我们可以复制该测试运行的确切条件，以便找到问题。

我们还增加了在我们自己的系统中模拟许多故障模式的能力。一个很好的例子是Elasticsearch（另一个“邪恶”测试）中的SearchWithRandomExceptionsTests测试用例。它引入（可预见的）随机失败来试图破坏我们的系统。如果Elasticsearch不能应对失败，那么我们就要加强它。从外部测试网络问题是很困难的，因此我们增加了模拟网络分区（或行为失常的节点）的能力，以更容易地增强我们的分布式模型（稍后将详细介绍）。

第二个方面是回顾Elasticsearch和Lucene今天的表现，分析结果，尽可能使它们更具弹性。例如，校验和并不是Lucene的一个组成部分（它是在更高的弹性搜索级别上完成的，用于恢复目的），这使得文件损坏很难检测，这一直困扰着我。现在，随着我们为Lucene奉献的更多人，我们有能力解决这个问题。（也将其添加到后面的列表中。）

那么，更具体地说，我们有什么计划让Elasticsearch和Lucene更有弹性？这是我们今天的首要任务。它往往会根据用户的反馈而改变：

Lucene Checksums

今天，我们很难判断Lucene索引是否损坏。Lucene 4.8为所有文件添加了校验和，对读取小文件和一些大文件进行校验和验证，还提供了一个更昂贵的合并过程选项，该合并过程还对所有文件进行校验和验证。我们需要确保我们有更多的校验和验证，至少在合并所有文件时。

Translog Checksum

正如在Lucene中使用校验和一样，我们可以改进如何在事务日志中进行校验和。今天我们太宽容了。

Validate Checksum on Snapshot

快照/还原是Elasticsearch 1.x中的一项新功能。在快照操作期间，我们实际上可以在从磁盘读取数据时验证校验和，如果校验和不匹配，则拒绝快照（并故障转移到副本）。

Validate Checksum on Recovery

与快照相同，我们可以在从主副本复制Lucene段时对其进行校验和，从而改进副本上的碎片恢复。

Sequence Numbers

我们计划为发生在primary上的操作分配一个序列号碎片。这个是一个非常有趣的特性，它将为Elasticsearch中的许多未来特性奠定基础。最明显的一点是在节点重新启动时加快副本恢复过程。目前，我们必须复制每一个不同的部分，随着时间的推移，这意味着每一个部分！序列号将允许我们只复制真正改变的数据。

Improved Zen

Elasticsearch中存在一个缺陷，当集群面临部分分区时，可能导致大脑分裂，即某些节点可以看到其他节点看不到的节点（2488）。这个bug已经打开了一段时间，最近受到了很多关注。我想特别谈谈我们是如何处理这个问题的。

首先，在Elasticsearch部署中，网络断开实际上是一个相对罕见的问题。一个更常见的问题是，由于非常重的负载或长时间的垃圾收集，节点没有响应。长时间无响应的节点可能会出现死机。通过提高节点的稳定性，我们也提高了簇的稳定性。

在Elasticsearch中，我们积极推广在关键集群中使用专用的主节点，以确保有3个节点的唯一角色是主节点，这是一个轻量级的操作责任。通过减少这些节点所做的资源密集型工作（无数据接收或搜索），我们大大减少了集群不稳定的机会。

即便如此，我们发现在大型集群下（我们的用户继续推着我们！）或大型集群状态（数千个索引），这些主节点仍处于不可接受的负载下。我们在这方面做了很多改进：将shard分配算法提高到100倍的速度和更轻量级，在发布大型集群状态时更有效地使用我们的网络堆栈，对集群状态中的映射进行频繁的批量更新，等等。所有这些工作都已被完全移植回最新的0.90.x版本，以及最近的1.x版本。

这反映了我们在弹性搜索中提高弹性的方法。我们关注那些最终导致我们在这个领域看到的大多数失败的问题（而且我们的项目非常流行，每个月有超过50万次的下载，所以我们看到了很多这样的问题），并首先解决这些问题。其他一些改进，如压缩字段数据结构减少内存使用、更好的缓存回收和减少垃圾回收，都间接地帮助提高了节点（从而提高了集群）的稳定性。

回到问题上来。为了正确地解决这个问题，以及将来可能出现的问题，我们首先必须能够可靠地复制这个问题。通过我们改进的测试基础设施，我们现在有了一个“模拟传输”，它允许我们模拟条件并重现问题。现在有了这个bug的轻量级测试，我们就可以开始解决它了。我们很清楚需要什么来解决这个问题，并在Elasticsearch中创建了一个分支来实现和测试解决方案。希望它能在不久的将来成为大师。

部分分割的大脑是一个真正的问题，我们需要解决。话虽如此，但在实践中却非常罕见。就我个人而言，在我协助的所有部署中，我从未见过这个bug。用户经常把他们的问题归咎于这个bug，但它几乎总是被证明是另一回事。这并不是说这个bug不重要。它是。但是它出现的频率非常低，特别是最近的Elasticsearch版本的优化资源使用和专用的主节点。通过首先解决资源使用问题，我们帮助了更多的用户，如果我们只关注大脑分裂的问题，我们将无法做到这一点。

最后，一个常见的问题是为什么我们不使用外部系统来解决这个问题。例如，我们的发现模块是可插入的，为什么我们不能只插入Zookeeper并使用它，而不是我们构建的东西。对我来说，这是我们恢复能力的核心。Zookeeper是一个优秀的产品，它是一个独立的外部系统，有自己的通信层。通过使用Elasticsearch中的发现模块本身的基础设施，特别是通信层，这意味着我们可以使用集群的“活跃度”来评估其健康状况。操作一直在集群上进行，读、写、集群状态更新。通过将我们对健康状况的评估与相同的基础设施联系起来，我们实际上可以构建一个更可靠、更具响应性的系统。我们并不是说，对于那些已经在其他地方使用Zookeeper的人，我们不会有一个正式的Zookeeper集成。但这将是旁边的一个硬化，内置，发现模块。

顺便说一句，对于一个涉及这些方面的现场问答环节，请看我几个月前在纽约Elasticearch会议上的问答，从55分钟开始。

如果您查看上一个Linux版本或上一个Java版本的更改日志，您会想：“我的应用程序是如何处理这些错误的？”？最后，我们的系统运行良好。Elasticsearch和Lucene非常受欢迎，很多人每天都用它们来制作令人惊叹的产品。我们不断地投资于修复：：所有的问题：：，我们希望这篇博文能让你对我们的方法有所了解。