前言

ElasticSearch考虑到大数据量的情况，集群有很多的部署模式，本篇不会具体进行演示了，只是说明一下有哪些架构可以选，及一些原理的简单介绍，如果要看具体操作的那么可以自行进行搜索，这不是本篇博客要介绍的内容

集群架构

普通集群

这个在我之前的文章中已经花了很大时间介绍了，而且对一些基础概念也进行了介绍，可以先看看那篇文章再回来看后面的东西：https://blog.csdn.net/zxc_user/article/details/128683854

单一职责集群

这群集群比普通集群就要好多了，不过也需要更多的服务器来支撑，如果你在同一个服务器部署多个es来模拟这种架构模式，那就没啥意义了

读写分离架构

在单一职责上对协同节点进行隔离，这是针对协调节点的

Hot & Warm 架构

冷热数据分离，这是对于数据节点来说的，有些数据可能没啥人访问，那么就可以归为冷数据，一些常访问的数据可以归为热数据，所谓的冷热是你业务上来决定的

ES跨集群搜索（CCS）

这也是ElasticSearch支持的一大特性，有时候我们一个es集群存的数据已经很大了，但是节点太多了，此时我们可以利用CCS这种机制再部署一个新的集群，当我们查询数据时根据elasticsearch提供的功能从多个不一样的集群获取数据

ES底层读写工作原理

ES写入数据的过程

1. 客户端发生数据key给coordinating节点
2. coordinating节点通过对key进行hash找到合适的node2节点处理
3. node2先写到主分片，然后再同步给副本分片
4. 副本分片数据处理完成返回给主分片信息
5. 主分片告诉客户端处理完成

ElasticSearch读数据原理

分两种模式

Id：直接找

全文索引：先从倒排索引表获取到id，再从id获取数据

写数据底层原理

上面说的是宏观层面的数据写逻辑，这里是微观层面的写逻辑

segment file: 存储倒排索引的文件，每个segment本质上就是一个倒排索引，每秒都会生成一个segment文件，当文件过多时es会自动进行segment merge（合并文件），合并时会同时将已经标注删除的文档物理删除。

commit point: 记录当前所有可用的segment，每个commit point都会维护一个.del文件，即每个.del文件都有一个commit point文件（es删除数据本质是不属于物理删除），当es做删改操作时首先会在.del文件中声明某个document已经被删除，文件内记录了在某个segment内某个文档已经被删除，当查询请求过来时在segment中被删除的文件是能够查出来的，但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉

translog日志文件: 为了防止elasticsearch宕机造成数据丢失保证可靠存储，es会将每次写入数据同时写到translog日志中。

os cache：操作系统里面，磁盘文件其实都有一个东西，叫做os cache，操作系统缓存，就是说数据写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中去

Refresh

将文档先保存在Index buffer中，以refresh_interval为间隔时间，定期清空buffer，生成 segment,借助文件系统缓存的特性，先将segment放在文件系统缓存中，并开放查询，以提升搜索的实时性

Translog

Segment没有写入磁盘，即便发生了当机，重启后，数据也能恢复，从ES6.0开始默认配置是每次请求都会落盘

Flush

删除旧的translog 文件

生成Segment并写入磁盘│更新commit point并写入磁盘。ES自动完成，可优化点不多