elasticsearch分布式架构原理

index -> type -> mapping -> document -> field
elasticsearch 7.x取消了type
mapping类似于schema信息
document代表一行数据
field代表一个字段值

elasticsearch读写流程底层剖析

(1)es写数据过程

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

(2)es 读数据过程

查询，GET某一条数据，写入了某个 document,这个 document 会自动给你分配一个全局唯一的id,doc id，同时也是根据 doc id 进行 hash 路由到对应的 primary shard 上面去。也可以手动指定 doc id，比如用订单 id，用户id。
你可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个shard上面去，从那个 shard 去查询
1)客户端发送请求到任意一个 node，成为 coordinate node
2)coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法，在 primaryshard以及其所有 replica 中随机选择一个，让读请求负载均衡
3)接收请求的 node 返回 document给 coordinatenode
4) coordinate node 返回 document给客户端

实际的 node 上的 primary shard 处理请求详细解析

1)先写入 buffer，在 buffer 里的时候数据是搜索不到的，同时将数据写入 translog 日志文件
2)如果 buffer 快满了，或者到一定时间，就会将 buffer 数据 refresh到一个新的 segmentfile中，但是此时数据不是直接进入 segment file 的磁盘文件的，而是先进入os cache 的。这个过程就是 refresh。
每隔1秒钟，es将 buffer 中的数据写入一个新的segment file，每秒钟会产生一个新的磁盘文件，segment file，这个 segment file 中就存储最近1秒内 buffer 中写入的数据
但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，每秒创建一个空的segment file，如果 buffer 里面有数据，默认1秒钟执行一次 refresh 操作，刷入一个新的segment file 中
操作系统里面，磁盘文件其实都有一个东西，叫做 os cache，操作系统缓存，就是说数据写入磁盘文件之前，会先进入 os cache，先进入操作系统级别的一个内存缓存中去
只要 buffer 中的数据被 refresh 操作，刷入 os cache
默认是每隔1秒 refresh 一次的,所以es是准实时的，因为写入的数据1秒之后才能被看到。
可以手动 refresh，就是手动将 buffer 中的数据刷入 os cache中，让数据可以立即被搜索到。
只要数据被输入 os cache中,buffer就会被清空了,因为不需要保留 buffer了,数据在translog里面已经持久化到磁盘去一份了
3)只要数据进入 os cache，此时就可以让这个 segmentfile 的数据对外提供搜索了

4)重复1~3步骤，新的数据不断进入 buffer 和 translog，不断将 buffer 数据写入一个又一个新的segment file 中去,每次 refresh 完 buffer清空,translog 保留。随着这个过程推进,translog会变得越来越大。当 translog达到一定长度的时候，就会触发 commit 操作。
buffer 中的数据，倒是好，每隔1秒就被刷到 os cache 中去，然后这个 buffer 就被清空了。
所以说这个 buffer 的数据始终是可以保持住不会填满es 进程的内存的。
buffer 中的数据，倒是好，每隔1秒就被刷到 os cache 中去，然后这个 buffer 就被清空了。
所以说这个 buffer 的数据始终是可以保持住不会填满es 进程的内存的。
每次一条数据写入 buffer，同时会写入一条日志到 translog日志文件中去，所以这个 translog日志文件是不断变大的，当translog 日志文件大到一定程度的时候，就会执行 commit 操作。
5)commit 操作发生第一步，就是将 buffer 中现有数据 refresh 到 os cache 中去，清空 buffer
6)将一个 commit point写入磁盘文件,里面标识着这个 commit point 对应的所有 segment file
7)强行将 os cache中目前所有的数据都 fsync到磁盘文件中去
translog 日志文件的作用是什么? 就是在你执行 commit 操作之前，数据要么是停留在 buffer中，要么是停留在 os cache中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。
所以需要将数据对应的操作写入一个专门的日志文件，translog 日志文件中，一旦此时机器宕机，再次重启的时候，es 会自动读取 translog日志文件中的数据，恢复到内存 buffer 和os cache中去。
8)将现有的 translog 清空，然后再次重启启用一个translog，此时 commit 操作完成。默认每隔30分钟会自动执行一次 commit,但是如果 translog过大,也会触发commit。整个 commit的过程，叫做 flush 操作。我们可以手动执行 ush 操作，就是将所有 os cache数据刷到磁盘文件中去。
9)translog 其实也是先写入 os cache 的,默认每隔5秒刷一次到磁盘中去所以默认情况下可能有5秒的数据会仅仅停留在 buffer或者 translog 文件的os cache 中,如果此时机器挂了.会丢失 5秒钟的数据。但是这样性能比较好，最多丢5秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync到磁盘，但是性能会差很多。
实际上你在这里，如果面试官没有问你 es 丢数据的问题，你可以在这里给面试官炫一把，你说，其实 es 第一是准实时的，数据写入1秒后可以搜索到，可能会丢失数据的，你的数据有 5秒的数据，停留在 buffer、translog os cache、segment file os cache 中，有5秒的数据不在磁盘上，此时如果宕机，会导致 5秒的数据丢失。
10)如果是删除操作，commit 的时候会生成一个.del文件，里面将某个 do 标识为 deleted状态，那么搜索的时候根据.del 文件就知道这个 doc 被删除了
11)如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据
12)buffer 每次refresh 一次，就会产生一个 segment file，所以默认情况下是1秒钟一个segmentfile，segmentfile 会越来越多，此时会定期执行 merge
13)每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point，标识所有新的 segment file，然后打开 segmentfile 供搜索使用，同时删除旧的 segment file