Es 介绍

介绍:分布式搜索引擎,底层lucene,主要是es集群
搞一个索引，这个索引可以拆分成多个 shard ，每个 shard 存储部分数据。拆分多个 shard 是有好处的，一是支持横向扩展，比如你数据量是 3T，3 个 shard，每个 shard 就 1T 的数据，若现在数据量增加到 4T，怎么扩展，很简单，重新建一个有 4 个 shard 的索引，将数据导进去；二是提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器上并行分布式执行，提高了吞吐量和性能。
接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有一个 primary shard ，负责写入数据，但是还有几个 replica shard 。 primary shard 写入数据之后，会将数据同步到其他几个 replica shard 上去。
通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊，还有别的数据副本在别的机器上呢。高可用了吧。
ES 集群多个节点，会自动选举一个节点为 master 节点，这个 master 节点其实就是干一些管理的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举一个节点为 master 节点。
如果是非 master 节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。
说得更简单一点，就是说如果某个非 master 节点宕机了。那么此节点上的 primary shard 不就没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。

es 写数据过程
 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node （协调节点）。
 coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node 。
 coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

es 读数据过程
 客户端发送请求到一个 coordinate node 。
 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以。
 query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
 fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

总结一下，数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。

Es大数据量优化:
     1)增加内存,最好内存大于数据量,至少一半
     2)Es存储过滤的字段,别的存放在mysql或者别的数据库
     3)预热_预热子系统
     4)冷热分离
     5)document模型设计合理,比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。
     6)不允许深度分页（默认深度分页性能很差）,否则是流搜索(类似抖音和微信)