Elasticsearch分布式架构原理(二)

总结：ES中存储数据的基本单位就是索引，比如说存储一些订单系统的销售数据，就因此在ES中创建一个索引，order=index。所有的销售数据就会都写到这个索引里去，一个索引就像一个数据库，二type就相当于表。一个索引可以有多个type。而mapping就相当于表的结构。往index的一个type里添加一行数据就叫做document，每个document有多个field，每一个field就代表这个document的一个字段值。
7、分片（shards）:单台机器无法存储大量数据，为解决这个问题，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index。
8、副本（replica）:任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器。副本两个主要原因：
（1）、高可用。它提供了高可用来防止分片或者节点宕机，主分片和副本分片绝对不能再同一台服务器上。
（2）、高并发。允许你的分片提供超出自身吞吐量的搜索服务。搜索行为可以在所有主分片和副本中并行执行。

总之，一个完整的流程就是，ES客户端将一份数据写入primary shards，主分片写入完成后会将所有的文档拷贝到副本分片中。客户端在读取数据时，会从主分片primary shard和副本分片replica shard中去读。
ES有多个节点，会自动选举一个节点为master节点，master节点其实就是干一些管理类的工作，比如为何元数据，负责切换primary shard和replica shard的身份之类。要是master节点宕机，集群就会选举下一个节点为master节点。如果是非master节点宕机了，那么master节点，就会让那个宕机节点上的primary shard的转移到replica shard上，如果修复了那台宕机的服务器，重启后，master节点就会控制将缺失的replica shard分配过去然后同步分片，让整个集群恢复正常。

二、写入数据的过程
2.1、简单流程：

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

备注：这个路由简单的说就是取模算法,比如说现在有3台服务器,这个时候传过来的id是5,那么5%3=2,就放在第3台服务器

2.2、写入数据的底层原理：

1. 数据文档会先写入到buffer里面，在buffer里面的数据是搜索不到的，同时也会将数据写入到translog日志文件之中
2. 如果buffer快满了，或是一段时间之后(定时)，就会将buffer数据refresh到一个新的OS cache之中，然后每隔1秒，就会将OS cache的数据写入到segment file之中，但是如果每一秒钟没有新的数据到buffer之中，就会创建一个新的空的segment file，只要buffer中的数据被refresh到OS cache之中，就代表这个数据可以被搜索到了。当然可以通过restful api 和Java api，手动的执行一次refresh操作，就是手动的将buffer中的数据刷入到OS cache之中，让数据立马搜索到，只要数据被输入到OS cache之中，buffer的内容就会被清空了。同时进行的是，数据到shard之后，就会将数据写入到translog之中，每隔5秒将translog之中的数据持久化到磁盘之中
3. 重复以上的操作，每次一条数据写入buffer，同时会写入一条日志到translog日志文件之中去，这个translog文件会不断的变大，当达到一定的程度之后，就会触发commit操作。
4. 将一个commit point写入到磁盘文件，里面标识着这个commit point 对应的所有segment file
5. 强行将OS cache 之中的数据都fsync到磁盘文件中去。
   解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。
6. 将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件
   补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。
7. 如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。
8. 如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。
9. buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作
10. 每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。

三、ES查询过程
3.1、查询过程
1、客户端发送一个请求给coodinate node.
2、协调节点将搜索的请求转发给所有的shard分片对应的主分片或副本分片。
3、query phase：被选中的shard将自己的搜索结果（就是唯一标识）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作。
4、fetch phase:接下来由协调节点，根据唯一标识也就是搜索结果去各个节点上进行拉取数据，然后返回给客户端。

3.2、查询的原理
查询大体上分为两个节点：query和fetch两个阶段，广播查询请求到所有的相关分片，并将他们的响应整合成全局排序后的结果结合，并把这个结果集合返回给客户端。

1、query阶段
1.当一个节点接收到一个搜索请求，这这个节点就会变成协调节点，第一步就是将广播请求到搜索的每一个节点的分片拷贝，查询请求可以被某一个主分片或某一个副分片处理，协调节点将在之后的请求中轮训所有的分片来分摊负载。
2.每一个分片将会在本地构建一个优先级队列，如果客户端要求返回结果排序中从from 名开始的数量为size的结果集，每一个节点都会产生一个from+size大小的结果集，因此优先级队列的大小也就是from+size，分片仅仅是返回一个轻量级的结果给协调节点，包括结果级中的每一个文档的ID和进行排序所需要的信息。
3.协调节点将会将所有的结果进行汇总，并进行全局排序，汇总得到排序结果。

2、取值阶段
1.查询过程得到的排序结果，标记处哪些文档是符合要求的，此时仍然需要获取这些文档返回给客户端
2.协调节点会确定实际需要的返回的文档，并向含有该文档的分片发送get请求，分片获取的文档返回给协调节点，协调节点将结果返回给客户端

四、更新过程
4.1、document的全量替换

1.这个就是用新的数据全部覆盖以前的数据
2.重新创建一个document并把原来的标记为delete
3.partial update, 就是制定需要更新的字段.

备注：全量更新是把数据找出来，然后在java代码中进行修改，然后在放进去
partial部分是直接提交需要修改的字段然后直接修改，在一个shard中进行，内部也是全量替换.
4.2、强制创建
就是不管原来的数据，直接强制创建一个新的。
4.3、删除过程
当要进行删除document的时候,只是把它标记为delete,当数据到达一定的时候再进行删除, 有点像JVM中标记清除法

Elasticsearch分布式架构原理(二)

原文：https://blog.51cto.com/liqingbiao/2537353