-------------------ELK(Elasticsearch+Logstash+Kiabana)-------------
ELK(Elasticsearch+Logstash+Kiabana)的原理？
安装过程：
1、安装Elasticsearch
2、 Logstash安装，logstash改配置，监听业务服务器的日志，将其输入；并且配置好每个业务系统输出到ES的索引是啥
2、安装Kinaba，连接ES地址，把日志显示到客户端
原理图：
Elasticsearch是存储数据.
Logstash是搜集、分析、过滤日志.
Kibana是客户端显示。
Elasticsearch的优点？和关系型数据库的区别是啥？
一、优点：是一个基于Lucene构建的，分布式全文搜索引擎。 还是一个分布式文档数据库，每个字段均是被索引的数据且可被搜索，快速存储、搜索和分析大量数据。还支持模糊分词查询
横向可扩展性:只需要增加台服务器，做一点儿配置，启动一下Elasticsearch就可以并入集群。
二、结构区别：
关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns) （提前创建表定义好字段）
Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields) （动态映射字段）
-------------------ELK+Kafka-------------
参考：https://blog.csdn.net/qq_36807862/article/details/81283568
？工作原理？
普通ELK缺点：Logstash运行占用CPU和内存较高，并且Client和server之间没有消息缓存，如果server宕机不可用，会存在消息丢失的风险；
改进：引入消息队列机制Kafka，保证了即使Logstash Server因故障停止运行，数据也会缓存下来，避免了数据丢失；
（还能再改进---官方推荐：将收集端logstash替换为beats，更灵活，消耗资源更少）
？的作用或优点？
-------------------Elasticsearch-------------
？ES集群核心原理？
1、每个索引会被分成多个分片shards进行存储，默认创建索引是分配5个分片进行存储。
每个分片都会分布式部署在多个不同的节点上进行部署，该分片成为primary shards。
注意：索引的主分片primary shards定义好后，后面不能做修改。
2、为了实现高可用数据的高可用，主分片可以有对应的备分片replics shards，replic shards分片承载了负责容错、以及请求的负载均衡(写主，读主备)。
注意: 每一个主分片为了实现高可用，都会有自己对应的备分片，主分片对应的备分片不能存放同一台服务器上(避免宕机就一起挂)。，主分片primary shards可以和其他replics shards存放在同一个node节点上。
？的作用或优点（为什么要使用Elasticsearch）？
1、（大型电商商品搜索系统、网盘搜索引擎）门户网站都用es查询，因为快，原因：做了分词查询，查询范围也广。（采用以往的mysql模糊查询，%在前面会放弃索引，全表扫面，百万级别，效率非常低）
1、ELK日志收集（现在kafka比它更高效）（同上）
?ES分词查询+自定义拓展热词?
//执行分词器信息查询命令（用默认的），只会显示a41、奥、迪.
存在问题1：中文单个字分词问题。
解决1：//下载ik插件---把ik放入es插件目录plugins下，然后再查分词器信息（换成ik），就不会再按中文单个字分词了。
存在问题2：王者荣耀，这样的词会分成王者和荣耀，没有‘王者荣耀’这个热词。
解决2：//自定义扩展字典---关键热词
在/usr/local/elasticsearch-6.4.3/plugins/ik/config目录下，自定义建个文件放入一些关键热词
比如，建个custom/new_word.dic文件，在里面放入：
王者荣耀
？ES数据结构？
索引-类型（最新版本移除）-文档-字段
？Term与Match区别？
Term查询不会对字段进行分词查询，会采用精确匹配。
Match会根据该字段的分词器，进行分词查询。
GET mymayikt/user/_search
{
"query": {
"term": {
"name": "xiaoming"
}
}
}
ES是如何解决高并发？
ES是一个分布式全文检索框架，隐藏了复杂的处理机制，内部使用 分片机制、集群发现、分片负载均衡请求路由。
？ES是如何解决分布式日志收集？
1、传统系统日志收集的问题：集群多台机器时，查问题日志需要查多台，很麻烦，效率低
2、Logstash操作工作原理：搜集输入、解析、输出日志.
3、分布式日志收集ELK原理： Logstash搜集输入、解析、输出日志， Elasticsearch是存储数据，Kibana是客户端显示。
4、Elasticsearch+Logstash+Kiabana整合
5、Logstash将数据推送到ES
6、Kiabana图形界面展示ES日志信息
请问mongodb ， elasticsearch ， mysql各有什么优缺点？
对比：
1、在存储上，mongodb和es是document格式的存储，mysql是行格式的、需要显式定义字段。
2、在架构上，es天然就是分布式的，很容易横向扩容，而mongo和mysql不行。
3、在针对场景下，es无法做到实时，而mysql和mongo可以，es需要额外考虑下场景是否适用。
4、在数据存储量及性能上，mysql由于其索引在数据量大到一定级别后会出现性能衰减，而mongo和es只要给足足够内存就没太大问题（mongo内存不足时性能衰减的更为厉害，es不明显）。
5、插入速度上如果正确的配置mysql其性能并不低，当然相对于正常状态mongo和es而言还是差了一个到多个量级（es>mongo>mysql）。查询速度这个主要看索引和数量，这个不太好说，mongo谜一样的索引选择曾经让我纠结过很久，在需要复杂关联查询的时候建议优先考虑mysql。
6、资源开销上当数据量上去了后如果为了维持性能的话，es吃内存的能力绝对可以傲视群雄，但毕竟没有不吃草就能跑的快的马儿。
易用性上当然是mysql>mongo>es，如果考虑使用mysql的话可以再考虑下postgresql，虽然小众点，但有些mysql功能上的缺失会让你写sql写到哭。 其实刨掉全文检索场景，mysql（5.6以后）加上良好的设计就能很好的支持绝大部分需求了，所以不要太过于纠结到底用啥了。
选择：
1、业务所需字段已经确定了，就用mysql，实时新增查询都挺快的。
2、但是某些场景下业务所需的字段不确定，需要实时新增新的字段且查询，用MongoDB方便点。
3、然后就是es，做大量数据的存储和查询，性能也不错，就是新插入的数据，并不会马上被搜索到，起码也得几秒钟之后才能检索出来。
Elasticsearch和MongoDB简要对比？
相同点：
1、都是以json格式管理数据的nosql文档型数据库。
2、都支持CRUD操作。
3、都支持聚合和全文检索。
4、都支持分片和复制。
5、都支持阉割版的join操作。
6、都支持处理超大规模数据。
7、目前都不支持事务或者叫支持阉割版的事务。
不同点：
1、es是java编写，通过RESTFul接口操作数据。mongodb是C++编写，通过driver操作数据。（es对java开发更有好，利于排查理解）
2、mongodb的分片有hash和range两种方式，es只有hash一种。
3、es是天生分布式，主副分片自动分配和复制，开箱即用。mongodb的分布式是由“前置查询路由+配置服务+shard集合”，需要手动配置集群服务。
4、内部存储ES是倒排索引+docvalues+fielddata。mongodb暂时未知。
5、es全文检索有强大的分析器且可以灵活组合，查询时智能匹配。mongodb的全文检索字段个数有限制。
6、es所有字段自动索引，mongodb的字段需要手动索引。
7、es非实时有数据丢失窗口。mongodb实时理论上无数据丢失风险。
-------------------ElasticSearch常见经典面试题-------------
ElasticSearch常见经典面试题
1.为什么要使用Elasticsearch?
因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段放入我们索引库里，可以提高查询速度。
2.Elasticsearch是如何实现Master选举的？
Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；
对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。
3.Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？
当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点,投票一半以上来解决脑裂问题；
当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。
4.详细描述一下Elasticsearch索引文档的过程。
协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。
shard = hash(文档ID) % (分片机器数)
当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh；
当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush；
在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。
flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时；
5.详细描述一下Elasticsearch更新和删除文档的过程
删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；
磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。
在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
6.详细描述一下Elasticsearch搜索的过程
搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。
每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。
9.Elasticsearch对于大数据量（上亿量级）的聚合如何实现？
Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关 .
10.在并发情况下，Elasticsearch如果保证读写一致？
可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。
14.ElasticSearch中的集群、节点、索引、文档、类型是什么？
群集是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
类型是索引的逻辑类别/分区，其语义完全取决于用户。
15.ElasticSearch中的分片是什么?
在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。
索引 - 在Elasticsearch中，索引是文档的集合。
分片 -因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素。
问题一：
什么是ElasticSearch？
Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式，多租户能力的全文搜索引擎。Elasticsearch是用Java开发的，根据Apache许可条款作为开源发布。
问题三：
Elasticsearch中的倒排索引是什么？
倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。倒排索引是一种像数据结构一样的散列图，可将用户从单词导向文档或网页。它是搜索引擎的核心。其主要目标是快速搜索从数百万文件中查找数据。
问题四：
ElasticSearch中的集群、节点、索引、文档、类型是什么？
群集是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
类型是索引的逻辑类别/分区，其语义完全取决于用户。
问题五：
ElasticSearch是否有架构？
ElasticSearch可以有一个架构。架构是描述文档类型以及如何处理文档的不同字段的一个或多个字段的描述。Elasticsearch中的架构是一种映射，它描述了JSON文档中的字段及其数据类型，以及它们应该如何在Lucene索引中进行索引。因此，在Elasticsearch术语中，我们通常将此模式称为“映射”。
Elasticsearch具有架构灵活的能力，这意味着可以在不明确提供架构的情况下索引文档。如果未指定映射，则默认情况下，Elasticsearch会在索引期间检测文档中的新字段时动态生成一个映射。
问题六：
ElasticSearch中的分片是什么？
在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。
索引 - 在Elasticsearch中，索引是文档的集合。
分片 -因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素。
问题七：
ElasticSearch中的副本是什么？
一个索引被分解成碎片以便于分发和扩展。副本是分片的副本。一个节点是一个属于一个集群的ElasticSearch的运行实例。一个集群由一个或多个共享相同集群名称的节点组成。
问题八：
ElasticSearch中的分析器是什么？
在ElasticSearch中索引数据时，数据由为索引定义的Analyzer在内部进行转换。 分析器由一个Tokenizer和零个或多个TokenFilter组成。编译器可以在一个或多个CharFilter之前。分析模块允许您在逻辑名称下注册分析器，然后可以在映射定义或某些API中引用它们。
Elasticsearch附带了许多可以随时使用的预建分析器。或者，您可以组合内置的字符过滤器，编译器和过滤器器来创建自定义分析器。
问题九：
什么是ElasticSearch中的编译器？
编译器用于将字符串分解为术语或标记流。一个简单的编译器可能会将字符串拆分为任何遇到空格或标点的地方。Elasticsearch有许多内置标记器，可用于构建自定义分析器。
问题十一：
启用属性，索引和存储的用途是什么？
enabled属性适用于各类ElasticSearch特定/创建领域，如index和size。用户提供的字段没有“已启用”属性。 存储意味着数据由Lucene存储，如果询问，将返回这些数据。
存储字段不一定是可搜索的。默认情况下，字段不存储，但源文件是完整的。因为您希望使用默认值(这是有意义的)，所以不要设置store属性 该指数属性用于搜索。
索引属性只能用于搜索。只有索引域可以进行搜索。差异的原因是在分析期间对索引字段进行了转换，因此如果需要的话，您不能检索原始数据。
