ES基础概念和集群概念

前言

思考一个问题：当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑问题：

• 用什么数据库好？(mysql、sybase、oracle、达梦、神通、mongodb、hbase…)
• 如何解决单点故障；(lvs、F5、A10、Zookeep、MQ)
• 如何保证数据安全性；(热备、冷备、异地多活)
• 如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)
• 如何解决统计分析问题；(离线、近实时)
• 如何快速进行检索？

安全性问题
可以通过主从备份(关系型数据库)或者副本备份(非关系型数据库)解决数据安全性问题

单点故障
关系型通过数据库代理中间件心跳监测，解决单点故障问题，非关系型数据库通过节点竞选机制解决单点问题；

解决检索和统计难题
关系型通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果，非关系型数据库先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

如何快速进行检索
mysql为了提高检索速度可以采用分表分库，建立索引等操作，但在大数据、文档全文检索环境下，mysql这些花里胡哨的操作根本就收效甚微，redis速度固然快，但redis是内存级的，面对PB级大数据环境下，内存则是显得那么无力。

ES读写为何速度那么快（史上最全面总结）

ES基础概念：

ES基础概念和ES的基础命令我们都会对比大家都已经滚瓜烂熟的mysql来进行讲解，但es集群其实和kafka非常相似，我们会参考kafka来进行对比；

Elasticsearch（ES）
是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。Elasticsearch还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，ES能够横向扩展至数以百计的服务器存储以及处理PB级的数据。可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。

是为高可用和可扩展而生的。可以通过购置性能更强的服务器或者升级硬件来完成系统扩展，称为垂直或向上扩展（Vertical Scale/Scaling Up）。另一方面，增加更多的服务器来完成系统扩展，称为水平扩展或者向外扩展（Horizontal Scale/Scaling Out）。尽管ES能够利用更强劲的硬件，垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展，通过向集群中添加更多的节点来分担负载，增加可靠性。ES天生就是分布式的：它知道如何管理多个节点来完成扩展和实现高可用性。这也意味你的应用不需要做任何的改动。

Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

索引Index
一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除（CRUD）的时候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。

能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录就是索引的意思，目录可以提高查询速度。

Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。

一般传统数据库，全文检索都实现的很鸡肋，因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表，如果数据量大的话即使对 SQL 的语法优化，也收效甚微。建立了索引，但是维护起来也很麻烦，对于 insert 和 update 操作都会重新构建索引。

基于以上原因可以分析得出，在一些生产环境中，使用常规的搜索方式，性能是非常差的

搜索的数据对象是大量的非结构化的文本数据。
文件记录量达到数十万或数百万个甚至更多。
支持大量基于交互式文本的查询。
需求非常灵活的全文搜索查询。
对高度相关的搜索结果的有特殊需求，但是没有可用的关系数据库可以满足。
对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。为了解决结构化数据搜索* 和非结构化数据搜索性能问题，我们就需要专业，健壮，强大的全文搜索引擎 。

这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。

经营一家网上商店，你可以让你的客户搜索你卖的商品。在这种情况下，你可以使用ElasticSearch来存储你的整个产品目录和库存信息，为客户提供精准搜索，可以为客户推荐相关商品。

当你想收集日志或者交易数据的时候，需要分析和挖掘这些数据，寻找趋势，进行统计，总结，或发现异常。在这种情况下，你可以使用Logstash或者其他工具来进行收集数据，当这引起数据存储到ElasticsSearch中。你可以搜索和汇总这些数据，找到任何你感兴趣的信息。

es做日志收集是，往往一条产品线的日志对应一个es索引，如下

类型Type
在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。
不同的版本，类型发生了不同的变化。5.x 支持多种 type，6.x 只能有一种 type，7.x 默认不再支持自定义索引类型（默认类型为： _doc），对标mysql数据表

文档
一个文档是一个可被索引的基础信息单元，也就是一条数据。

比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON（Javascript Object Notation）格式来表示，而 JSON 是一个到处存在的互联网数据交互格式。在一个 index/里面，你可以存储任意多的文档。类似于mysql的数据行

字段Field
相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。

映射Mapping
mapping 是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

Node节点
节点是单个服务器实例，它是群集的一部分，可以存储数据，并参与群集的索引和搜索功能。就像一个集群，节点的名称默认为一个随机的通用唯一标识符（UUID），确定在启动时分配给该节点。如果不希望默认，可以定义任何节点名。这个名字对管理很重要，目的是要确定你的网络服务器对应于你的ElasticSearch群集节点。

我们可以通过群集名配置节点以连接特定的群集。默认情况下，每个节点设置加入名为“elasticSearch”的集群。这意味着如果你启动多个节点在网络上，假设他们能发现彼此都会自动形成和加入一个名为“elasticsearch”的集群。

在单个群集中，您可以拥有尽可能多的节点。此外，如果“elasticsearch”在同一个网络中，没有其他节点正在运行，从单个节点的默认情况下会形成一个新的单节点名为"elasticsearch"的集群。

Cluster 集群
群集是一个或多个节点（服务器）的集合， 这些节点共同保存整个数据，并在所有节点上提供联合索引和搜索功能。一个集群由一个唯一集群ID确定，并指定一个集群名（默认为“elasticsearch”）。该集群名非常重要，因为节点可以通过这个集群名加入群集，一个节点只能是群集的一部分。

确保在不同的环境中不要使用相同的群集名称，否则可能会导致连接错误的群集节点。例如，你可以使用logging-dev、logging-stage、logging-prod分别为开发、阶段产品、生产集群做记录。

Shared分片
索引可以存储大量的数据，这些数据可能超过单个节点的硬件限制。例如，十亿个文件占用磁盘空间1TB的单指标可能不适合对单个节点的磁盘，基本能存储下来，服务仅从单个节点的搜索请求也会速度很慢。

为了解决这一问题，Elasticsearch提供细分你的指标分成多个块称为分片的能力。当你创建一个索引，你可以简单地定义你想要的分片数量。每个分片本身是一个全功能的、独立的“指数”，可以托管在集群中的任何节点。

Shards分片的重要性主要体现在以下两个特征：

• 分片允许您水平拆分或缩放内容的大小
• 分片允许你分配和并行操作的碎片（可能在多个节点上）从而提高性能/吞吐量，这个机制中的碎片是分布式的以及其文件汇总到搜索请求是完全由ElasticSearch管理，对用户来说是透明的。

分片shareds类似于kafka的partition，这两者同时也可以对标mysql的分表分库技术；

Replic副本
在同一个集群网络或云环境上，故障是任何时候都会出现的，拥有一个故障转移机制以防分片和结点因为某些原因离线或消失是非常有用的，并且被强烈推荐。为此，Elasticsearch允许你创建一个或多个拷贝，你的索引分片进入所谓的副本或称作复制品的分片，简称Replicas。

Replicas的重要性主要体现在以下两个特征：

• 副本为分片或节点失败提供了高可用性。为此，需要注意的是，一个副本的分片不会分配在同一个节点作为原始的或主分片，副本是从主分片那里复制过来的。
• 副本允许用户扩展你的搜索量或吞吐量，因为搜索可以在所有副本上并行执行。ES中的shared分片机制和kafka的分区partition机制市一样的，但他们的副本机制有差异
  共同点都是副本为分片或节点失败提供了高可用性。但kafka中副本的作用仅限于此了，但ES操作以在所有副本上并行执行，es中副本地位更高

ES分布式集群概念 vs Kafka

es Index VS kafka topic
Index可以类比为mysql的数据库那么topic也依然可以，比如你经验一家网店，那么你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。分布式环境下这些业务会位于不同的模块下，甚至部署到不同的服务器上，kafka中我们同样可与将这些不同的业务抽象为不同的主题，比如constomTopic，productTopic，orderTopic来供消费者消费和生产者写入。

es shared VS kafka partition

• 概念层面：es和kafka都是支持分布式环境的 =>Index和topic不会局限于一台服务器，否则在无限的消息堆积中很容易超出单机性能极限，还有单点故障问题，无法保证高可用，无法负载均衡，es和kafka跨分区的基本单位分别就是shared和parition，而且这两者都是一旦创建好就不能再变化了，因为es中依赖通过分区的数目来计算写入的位置,数目上没有严格限制，数量可以大于集群节点数量，也就是一个节点可以有多个分片or分区。

es replica VS kafka replica

• 首先数据都是写入到主分区/主分片后再把数据同步到副本
• 副本的意义主都是保证分布式环境下的高可用HA，但 kafka中副本单纯是做备份或分区后续，es中的副本功能更强大，不单纯是做备份和候选分片，而且也可以参与到es数据查询业务中，所以后续虽然es分片数量后期无法扩展，但我们可以通过扩展副本的形式来增强并发吞吐量
• 如果主分区/主分片挂断，副本都会站出来竞争产生一个新的主分区/主分片，kafka中通过ISR机制，而es中依赖？？？？？？？
• 副本的数量不能大于节点的数量，大于节点数相当于一个服务器会有针对同一分片/分区两个及以上的数据，这被认为是没有意义的事；

集群数据问题
主分片才能进线增删改查，副本分片可以进行查询，我们的插入请求首先会落到主结点上，主节点会根据路由公式：hash(id) % 分片数量来计算插入到那个结点的分片上，根据计算由结点服务器node1处理插入请去，数据a插入到node1结点的主分片p1，数据插入成功后，p1对应的两个副本r0和r1也会收到同步数据a的请求，副本插入成功后反馈主结点，主节点再响应客户端数据插入成功

• 响应策略可以优化来减少响应时间，比如consistency三个选项
• 如果当前集群只有三个结点服务器的话，那就意味着集群中每台服务器都会有这个结点，查询数据a时，请求首先会落到主分片p1上，此时es服务器采用轮询的负载均衡策略，也就是三台服务器结点依次处理查询请求，大大提高了并发吞吐量
• 查询操作也类似，客户端查询请求到协调节点，协调节点计算数据所在分配以及全部的副本位置，并且轮询他们所在的全部结点，将请求转发到具体结点，结点返回查询结果，在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

集群安全问题
集群健康值:green( 6 of 6 )：表示所有 6 个分片（包括 2 个主分片和 4个副本分片）都在正常运行
刚创建时：

此时模拟副本分片挂掉的情况（关闭node-1003），此时集群健康值: yellow (4 of 6)

此时模拟副本主分片挂掉的情况,如果有主分片挂掉那么集群健康值就为red，此外需要注意，es集群只至少要启动两个及以上节点

这里有个坑，当集群刚配置完毕我们只启动第一台服务器节点时，如下，所有分片集中到这个节点上，后续就不会再出现这种情况了，而是这个集群至少两个节点启动才能正常运行

但此时其它服务器启动失败or启动后没有被纳入该集群中，此时需要通过情况data数据甚至重新建立集群的方式恢复过来

kafka vs es集群的发现机制???

# 9300 端口为 Elasticsearch 集群间组件的通信端口， 9200 端口为浏览器访问的 http协议 RESTful 端口。
如何在elk中精准查到group=kf_开头的全部连接（ngnix-access里）

transport.tcp.port: 9302

discovery.seed_hosts,第一台节点（1001）的话不需要配置，这个主要是告诉后续启动的服务器，他们集群中有哪些其它节点，比如：
node1002配置：discovery.seed_hosts: ["localhost:9301"]
node1003配置：discovery.seed_hosts: ["localhost:9301", "localhost:9302"]
由此集群的启动顺序也是node1001，node1002，node1003

验证：把node1003的服务配置注释掉那么即使启动该服务器也无法被加入到节点中，而且会报错
master not discovered or elected yet, an election requires at least 2 nodes with ids from [fR3pcma8Q2C78mEC-nFPyA, pAorzSQfQ1aZZAfKDS2WUg, di9Va3EXRkm7E6MaOj5sNg]，
因为es为了防止某个结点被意外加入到某个集群，那么这个节点不仅要配置同样的集群名，唯一的节点名，还要配discovery.seed_hosts标明和那些节点一个集群

同理，集群正常运行过程中，node1001挂掉，后续又恢复重启，那么如果想在重启的同时被加入到节点中，则需要如下配置
discovery.seed_hosts: ["localhost:9302", "localhost:9303"]

结点挂掉，后续又重启再次被加入到集群的过程中

副本数量超限案例

kafka写操作 vs es写操作

kafka的producor主要按如下操作：

• 指明 partition 的情况下，直接将指明的值直接作为 partiton 值；
• 没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition
  数进行取余得到 partition 值；
• 既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后
  面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition
  值，也就是常说的 round-robin 算法

es的写操作：
虽然es的写操作会按照公式

shard = hash(routing) % number_of_primary_shards

来确定将data写入到那个分片上，但在写入的请求到达es集群前，es集群还没从request中获取到数据，那么此时自然不知道请求该发往哪个分区，实时上，请求是随机发往es的，率先接收到请求的服务器节点我们称之为协调节点，协调节点会根据计算发现目标服务器上然后把请求转发给目标主分片节点，然后同步到各个副本，然后反馈用户response

kafka读操作 vs es读操作

kafka(消费者)读操作的三种方式：kafka消费者分区的分配的三种机制

es读操作：
协调节点收到请求数据，这里协调阶段不单单是计算请求的主分片位置，而且连同相关副本的位置一同计算出来，然后负载均衡轮询所有节点，请求转发到主分片服务器，然后再由主分片服务器节点转发给用户

注意：无论es还是kafka写操作都是在主分片上面完成之后才能被复制到相关的副本分片。

两者集群对请求的处理

• kafka中请求的处理非常简单，无论是消费者还是生产者都需要绑定一到多个主题来进行消费，这样请求会围绕着主题进行发送，其中有三种方法决定请求发往那个分区。
• 我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。在下面的例子中，如果将所有的请求发送到Node 1001，我们将其称为协调节点coordinating node。当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。我们把这种操作称为分片控制

数据安全策略
在默认设置下，即使仅仅是在试图执行一个写操作之前，主分片都会要求必须要有规定数量quorum的分片副本处于活跃可用状态，才会去执行写操作（其中分片副本 可以是主分片或者副本分片）。这是为了避免在发生网络分区故障的时候进行写操作，进而导致数据不一致。 规定数量即
consistency 参数的值可以设为：

• one ：只要主分片状态 ok 就允许执行写操作。
• all：必须要主分片和所有副本分片的状态没问题才允许执行写操作。
• quorum：默认值为quorum , 即大多数的分片副本状态没问题就允许执行写操作

数据一致性问题，和kafka基本一致，都是按数据安全级别由高到低分为三种策略，只不过kafka中的参数值是ack，es中参数值是consistency

ELK是什么？
ELK=elasticsearch+Logstash+kibana
elasticsearch：后台分布式存储以及全文检索
logstash: 日志加工、“搬运工”
kibana：数据可视化展示。

logstash作为日志收集工具收集相关业务日志，存储到es中，es中的数据通过kibana视图工具展示给运维人员，ELK架构为数据分布式存储、可视化查询和日志解析创建了一个功能强大的管理链。 三者相互配合，取长补短，共同完成分布式大数据处理工作。

分析日志的用处：假如一个分布式系统有 1000 台机器，系统出现故障时，我要看下日志，还得一台一台登录上去查看，是不是非常麻烦？

但是如果日志接入了 ELK 系统就不一样。比如系统运行过程中，突然出现了异常，在日志中就能及时反馈，日志进入 ELK 系统中，我们直接在 Kibana 就能看到日志情况。如果再接入一些实时计算模块，还能做实时报警功能。

这都依赖ES强大的反向索引功能，这样我们根据关键字就能查询到关键的错误日志了。

elk+kafka+springaop完成日志收集demo