ElasticSearch定位

Elasticsearch是一个基于lucene的分布式、RESTful 风格的全文搜索引擎

特性

• 支持sql（需要x-pack-core插件）
• 水平拓展性好
• 支持结构数据和非结构化数据
• 准实时

Elasticserach的架构

Elasticsearch的层级

索引机制

倒排索引

Es作为全文搜索引擎，与传统的数据库不同的是，采用的是倒排索引，由传统的k-v，转向v-k,按分词规则切分数据，由此来建立索引，一个value的索引指向多个文档

索引更新与近实时搜索

索引不支持更新，而是采用重新建立索引的方式，使用段更新的方式，elasticsearch先将数据写入内存缓存，在异步写入文件缓存，此时便可以被搜索到了，这也是被被成为近实时的原因，然后在积累了一定数量的更新后在持久化到硬盘里面

优点

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够
• 的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

缺点

当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如 果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的 数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。

恢复机制

elasticsearch使用translog作为恢复点，elasticsearch每次修改translog都会记录，translog会先写入文件缓存，会到30分钟后或者translog到达一定程度再写入硬盘

Elasticsearch的读写机制

写机制

乐观锁机制

Elasticsearch采用乐观锁。乐观锁是指修改期间并不会对数据上锁，而是对数据加上乐观锁，获取版本号，判断版本号是否与其修改的数据版本号是否一致，一致则成功，不一致失败。 顺序如下

• 1. 客户端向 Node 1 发送更新请求。
• 2. 它将请求转发到主分片所在的 Node 3 。
• 3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。 如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃。
• 4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功。

读机制

允许从主或者副本读取

从主分片或者副本分片检索文档的步骤顺序：

• 1. 客户端向 Node 1 发送获取请求。
• 2. 节点使来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下，它将请求转发到 Node 2 。
• 3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。

集群架构

名词解释：

• shards:代表索引分片，ElasticSearch可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。
• EsMaster:主节点，可以临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索，在流量增长时，该主节在流量增长时，该主节点不会成为集群的瓶颈。
• EsNode:ElasticSearch节点，一个节点就是一个ElasticSearch实例。
• replicas:代表索引副本，ElasticSearch可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高Elasticsearch的查询效率，Elasticsearch会自动对搜索请求进行负载均衡。
• recovery:代表数据恢复或叫数据重新分布，Elasticsearch在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。
• GateWay:代表Elasticsearch索引快照的存储方式，Elasticsearch默认是先把索引存放到内存中，当内存满了时再持久化到本地硬盘。gateway对索引快照进行存储，当这个Elasticsearch集群关闭再重新启动时就会从gateway中读取索引备份数据。Elasticsearch支持多种类型的gateway，有本地文件系统（默认），分布式文件系统，Hadoop的HDFS和amazon的s3云存储服务。
• transport:代表Elasticsearch内部节点或集群与客户端的交互方式，默认内部是使用tcp协议进行交互，同时它支持http协议（json格式）、thrift、servlet、memcached、zeroMQ等的传输协议（通过插件方式集成）

集群选举模式

选举方式

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分

• 对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
• 如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。 master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。也可以使用zookeeper选举。

避免脑裂

减少误判：discovery.zen.ping_timeout节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。 选举触发: discovery.zen.minimum_master_nodes:1 该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值， 且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为（n/2）+1，n为主节点个数 （即有资格成为主节点的节点个数） 角色分离：即master节点与data节点分离，限制角色 主节点配置为：node.master: true node.data: false 从节点配置为：node.master: false node.data: true（该参数可避免主节点由于负载过大而崩溃）

缓存机制

ElasticSearch缓存主要分三种：Query Cache、Fielddata Cache、Request Cache。

• Query Cache：属于Node级别的缓存，是对一个查询中包含的过滤器执行结果进行缓存。
• Fielddata Cache：Fielddata是专门针对分词的字段在查询期间的数据结构的缓存。
• Request Cache：Shard级别的缓存，是为了缓存“分片级”的本地结果集。