为什么要使用 Elasticsearch? （或 回答什么是ES？）

在我们常用的业务场景中我们往往采用模糊查询进行数据的搜索，而模糊查询如果用全表扫描，在百万数据量的情况下， 查询效率是非常低下。而使用Elasticsearch ，做一个全文索引， 可以提高查询速度。 ES是一个基于Lucene库的搜索引擎，它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。 使用一种称为 倒排索引 的结构，倒排索引会在存储数据时将关键词和数据进行关联，保存到倒排表中，然后查询时，将查询内容进行分词后在倒排表中进行查询，最后匹配数据 ，可以提高查询速度。

ES还有以下方面优势

1. 横向可扩展性：只需要增加一台服务器，做一点儿配置，启动一下ES进程就可以并入集群；
2. 分片机制提供更好的分布性：同一个索引分成多个分片（sharding），分而治之的方式来提升处理效率；
3. 高可用：提供复制（replica）机制，一个分片可以设置多个复制，使得某台服务器宕机的情况下，集群仍旧可以照常运行，并会把由于服务器宕机丢失的复制恢复到其它可用节点上

elasticsearch的倒排索引

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。

而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。

有了倒排索引，就能实现o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。

正向索引 : 基于文档id 建索引,查询词条必须先找到文档,而后判断是否包含词条

倒排索引 : 对文档内容分词,对词条建索引,记录词条所在文档的信息,查询时根据词条查询到文档id 然后获取文档

Elasticsearch中Master选举

Master选举中的几个重要角色

• 主节点（active master）：一般指的是集群中活跃的主节点，每个集群中只能有一个。
• 候选节点（master node）：具备master角色的节点默认都有“被选举权”，即是一个候选节点。候选节点可以参与Master选举过程
• 投票节点（master node）：每个候选节点默认都有投票权，即每个候选节点默认都是一个投票节点，但如果配置了“voting_only ”的候选节点将只有选举权而没有被选举权，即仅投票节点。
• 专用主节点：即 node.roles: [master]，一般指的是只保留master角色的候选节点。
• 仅投票节点：即 node.roles: [master, voting_only]，指仅具备选举权，而被阉割了被选举权的master节点。仅投票节点的意义是在出现平票的时候投出关键票（决胜票）。仅投票节点因为没有被选举权，因此永远不会被选举为active master,即永远不会成为活跃的主节点，因此通常同时配置为数据节点，以提高资源利用率。

何时触发选举

节点失效检测

在ES中有两个和选举相关的工作进程专门用于检查节点的存活状态，分别为：

• NodesFaultDetection：即NodesFD，用于定期检查集群中的节点是否存活。 MasterFaultDetection：即MasterFD，作用是定期检查Master节点是否存活。 他们分别会通过 ping 的方式定期检测集群中的普通节点和 master 节点是否存活。

触发选举的两种情况

• 当master-eligible节点数量小于法定票数：当主节点侦测到候选节点数量小于法定票数的时候，会主动放弃主节点身份。
• 当主节点宕机。

选主流程

前置前提：

1. 只有候选主节点（master：true）的节点才能成为主节点。
2. 最小主节点数（min_master_nodes）的目的是防止脑裂。

选举流程大致描述如下：

第一步：确认候选主节点数达标，elasticsearch.yml 设置的值

discovery.zen.minimum_master_nodes；

第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回；

若两节点都为候选主节点，则 id 小的值会主节点。

第三步：Master节点会尝试重启故障机

第四步：数据同步，Master会将宕机期间丢失的数据同步到重启机器对应的分片上去

Elasticsearch分片副本？

​ Elasticsearch使用分片（shard）和副本（replica）来实现分布式存储和高可用性。分片是将索引划分成多个部分，每个部分都是一个独立的Lucene索引。而副本则是分片的备份，每个分片可以有多个副本。

​ 默认情况下，Elasticsearch会为每个索引创建5个主分片和1个副本，总共会有10个分片（5个主分片+5个副本分片）。这意味着，每个索引的数据会被划分成10个部分，并且每个部分都会有一个主分片和一个副本分片。这种设置对于小规模索引来说已经足够，但是在面对大规模的数据集时，我们可能需要进行调整。

分片与副本的区别

​ 当分片设置为5时，elasticsearch就会把存储数据均衡的分配到5个分片上，当进行查询时，elasticsearch会把查询发送到每个分片上，并将结果组合在一起

​ 而副本，就是对这个5个分片的一种复制。分片是对数据的一种分割，总的数据依旧只有一份，这样可以保证查询的高效性，副本则是复制多份分片的数据，这样可以保证数据的高可靠性，防止数据丢失。

Elasticsearch数据备份和恢复

​ ES提供快照和恢复功能，我们可以在远程文件系统仓库（比如共享文件系统、S3、HDFS等）中单独给部分索引或者整个集群创建快照。这些快照对备份非常有用，它们能相对较快地被恢复。

​ 快照是增量的，可以包含在多个ES版本中创建的索引。如果在一个快照中的任何索引时在不兼容的ES版本中创建的，你将不能恢复该快照。

​ 在升级前备份数据的时候，如果快照中的索引是在与你升级版本不兼容的ES版本中创建的，那么这些快照将不能被恢复。

快照仓库

​ 必须先注册一个快照仓库，然后才能进行快照和恢复操作。建议为每个主版本创建一个新快照仓库。有效的仓库设置取决于仓库类型。

​ 如果多个集群注册同一个快照仓库，只有一个集群可以对仓库进行写访问，其他所有集群应该设置该仓库为 readonly 模式。

​ 跨主版本时快照格式可能会改变，所以不同版本的集群写同一个快照仓库，某个版本写的快照可能对其他版本不可见，仓库快照也存在问题。ES不支持仓库对所有集群设置为readonly，其中一个集群和不同主版本的多个集群一起工作。

curl -X PUT "localhost:9200/_snapshot/my_backup" -H 'Content-Type: application/json' -d'
{
  "type": "fs",
  "settings": {
    "location": "my_backup_location"
  }
}

仓库确认

仓库被注册之后，会立即在所有master和data节点上被验证以确保对当前集群所有的节点有效。在注册或者更新仓库时，参数verify可以显示禁用仓库核实确认操作：

curl -X PUT "localhost:9200/_snapshot/my_unverified_backup?verify=false" -H 'Content-Type: application/json' -d'
{
  "type": "fs",
  "settings": {
    "location": "my_unverified_backup_location"
  }
}

验证过程可以通过下面的命令手动执行：

curl -X POST "localhost:9200/_snapshot/my_unverified_backup/_verify"

上面返回一个仓库验证成功的节点列表或者验证失败时的错误信息

创建快照

一个仓库可以拥有同一个集群的多个快照。在一个集群中快照拥有一个唯一名字作为标识。在仓库 my_backup 中创建名字为 snapshot_1 的快照，可以通过执行下面的命令来实现：

curl -X PUT "localhost:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true"

参数 wait_for_completion 决定请求是在快照初始化后立即返回（默认），还是等快照创建完成之后再返回。快照初始化时，所有之前的快照信息会被加载到内存，所以在一个大的仓库中改请求需要若干秒（甚至分钟）才能返回，即使参数 wait_for_completion 的值设置为 false。

默认情况下，创建一个快照会包含集群中所有打开和启动状态的索引。可以通过在创建快照的请求体中定义索引列表来改变这个默认处理：

curl -X PUT "localhost:9200/_snapshot/my_backup/snapshot_2?wait_for_completion=true" -H 'Content-Type: application/json' -d'
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
}

要包含到快照中索引列表可以使用支持多个索引语法的 indices 参数来指定。快照请求也支持 ignore_unavailable 选项，该选项设置为 true 时，在创建快照时会忽略不存在的索引。默认情况下，如果选项 ignore_unavailable 没有设值，一个索引缺失，快照请求会失败。 通过设置 include_global_state 为 false，可以阻止集群全局状态信息被保存为快照的一部分。默认情况下，如果如果一个快照中的一个或者多个索引没有所有主分片可用，整个快照创建会失败，该情况可以通过设置 partial 为 true 来改变。

快照名可以通过使用 date_math_expressions 来自动获得，和创建新索引时类似。注意特殊字符需要 URI 转码处理。

例如，在名字中使用当前日期，比如 snapshot-2018.05.11，来创建快照，可以使用如下命令完成：

PUT /_snapshot/my_backup/<snapshot-{now/d}>
curl -X PUT "localhost:9200/_snapshot/my_backup/%3Csnapshot-%7Bnow%2Fd%7D%3E"

索引的快照过程是增量的。在创建索引快照的过程中，ElasticSearch会分析仓库中已经存在的索引文件，只拷贝那些在最后一次快照之后被创建或者更新的文件。That allows multiple snapshots to be preserved in the repository in a compact form. 快照过程以非阻塞的方式执行，所有的索引和搜索操作都可以对正在被创建快照的索引继续执行。一个快照表示的是这个索引在快照被创建时间点的索引视图，所以在索引过程开始之后被添加到索引中的记录不会出现在快照中。快照过程会立即在已经启动的主分片上开始并且不会在此时重新定位。在版本 1.2.0 以前，如果共同快照中的索引在集群中发生任何重新定位或者初始化（the cluster has any relocating or initializing primaries of indices participating in the snapshot），快照操作将失败，从 1.2.0 版本开始，ElasticSearch 会等重新定位或者初始化主分片完成之后再进行快照操作。

除了创建每个索引的备份，快照过程也能存储全局集群元数据，包括持久化的集群设置和模版。临时设置和注册的快照仓库不会存储为快照的一部分。

任何时候，在集群中只能有一个快照过程被执行。当创建一个特定分片的快照时，该分片不能移动到另一个节点，这会干扰（interfere with）平衡进程和分配过滤（allocation filtering）。ElasticSearch 一旦在快照完成之后才能移动分片到其他节点。

部分还原

​ 默认情况下，如果参与恢复操作的一个或者多个索引没有全部可用分片的快照，整个恢复操作将会失败。比如部分分片快照备份操作失败，上面的情况就会发生。这种情况依然可以通过设置 partial 为 true 来实现快照的恢复。注意在这种情况下，只有成功完成快照备份的分片才会被还原，而所有丢失的 其它分片将被创建成空分片。

在实际应用中，为了确保数据的一致性和完整性，通常会在备份时确保索引处于read-only状态，并且可能需要结合特定的快照生命周期管理策略（Snapshot Lifecycle Management, SLM）来自动化日常备份任务。此外，大型集群在执行备份和恢复操作时需要注意资源分配和性能影响。

解释Elasticsearch中的脑裂问题，并提出相应的预防和解决措施。

问题描述：

Elasticsearch集群的“脑裂”（Split-brain）问题指的是在一个分布式系统中，由于网络分区或者其他故障原因，原本统一的集群被分割成两个或多个独立的部分，每个部分都足够大以至于能够独立选举出自己的主节点（Master Node）。这样，就会有两个或更多的主节点同时存在，分别领导各自的子集群，它们之间无法通信，从而导致数据不一致性和潜在的数据丢失等问题。

在Elasticsearch集群中，脑裂可能导致以下问题：

• 数据冲突：在不同的主节点上进行的操作可能会对同一份数据产生冲突，比如在不同分区都有写操作，导致数据不一致。
• 资源浪费：各个分区可能继续处理请求并分配资源，但由于彼此隔离，整体集群的资源没有得到有效利用。
• 安全性风险：两个或多个主节点并发运行，可能导致错误的决策和意外的数据删除或修改。

预防和解决措施：

1. 避免单点故障：配置至少三个Master-eligible节点，确保任何时刻都有足够的节点参与主节点选举，达到法定人数（quorum），防止因为网络分区导致错误的主节点选举。

2. 设置discovery.zen.minimum_master_nodes：

   • 这个设置值应该大于等于 (N/2 + 1)，其中 N 是Master-eligible节点的数量。这样可以确保只有当大多数节点可见时才会选举出主节点，有效避免脑裂发生。

• 然而，在 Elasticsearch 7.x 版本之后，此参数已被弃用，取而代之的是自动化的逻辑，不再需要手动设置 discovery.zen.minimum_master_nodes。新版本的 Elasticsearch 自动计算 quorum 并确保主节点选举的安全性。

3. 合理的网络设计和监控：

   • 优化网络架构，减少网络分区的可能性，并实施积极的网络监控，及时发现和修复网络故障。
   • 使用跨可用区部署，增加网络冗余。

4. 数据安全策略：

   • 配置主节点间的通信心跳间隔和超时时间，确保即使在网络波动时也能快速识别和处理问题。
   • 使用集群健康检查工具和报警系统，一旦检测到脑裂现象，立即通知运维人员介入。

5. 数据一致性保障：

   • 对于已经发生的脑裂，在网络恢复后，集群会自动尝试重新选举主节点，并合并数据。但为了避免数据冲突，可能需要人工干预和审计，甚至可能需要从备份恢复数据以确保一致性。

6. 哨兵服务集成：

   • 类似于Redis Sentinel的概念，可以通过外部的监控和管理服务（如Elasticsearch官方推荐的Elastic Cloud Enterprise或开源项目如Monitorama等）对集群健康状况进行更严格的监控和控制，能够在发生脑裂时自动采取纠正措施。

总之，预防Elasticsearch集群脑裂的关键在于合理配置集群参数、强化网络稳定性、加强监控和自动化管理，以及制定应急恢复预案。