本章主要介绍ES的分布式架构，ES的分布式存储主要依赖于分片， 分片又分为主分片和副本分片
Primary Shard(主分片)
Primary Shard可以将索引的数据分散到多个Data Node上， 实现存储的水平扩展，主分片个数在索引创建的时候指定，后续默认不可更改，如果要更改，必须重建索引。
Replica Shard(副本分片)
Replica Shard的引入是为了提高数据可用性。一旦主分片丢失，副本分片可以晋升到主分片。副本分片可以动态调整的。副本分片可以服务于读请求，因此通过增加副本分片可以提升系统的整体吞吐量。
分片数的设置要合理
主分片数过小，集群无法通过增加节点实现索引数据的扩展。主分片数过大，会导致单个分片的容量过小，一个节点上有过多分片，影响性能。
副本分片的设置过多影响集群的整体写入性能。
故障转移
下图集群有三个节点组成，一个索引包含三个主分片， 每个主分片的副本数是1。
上图中节点1是master节点，节点1出现故障之后，集群重新选举master节点。Node 3中的R0变成了P0，R0和R1重新分配。
分片的内部原理
分片（Shard）实际上是一个Lucene的实例，从文件系统表现上看就是存储了一系列文件的目录。一个Shard由许多独立的Segment组成, Segment中包含了文档中的字典、倒排索引。所有的Segments数据都存储_<segment_name>.cfs的文件中。
随着索引数据的不断增长，segment数量也会逐渐变多，查询性能也会降低，ES内部会开启一个线程将小的Segment合并成大的Segment，减少碎片化，降低文件打开数量，提升IO性能。
Segment 文件是不可变更的。当一个 Document 更新的时候，实际上是将旧的文档标记为删除，然后索引一个新的文档。在 Merge 的过程中会将旧的 Document 删除掉。具体到文件系统来说，文档 A 是写入到 <segment_name>.cfs 文件里的，删除文档 A 实际上是在<segment_name>.del文件里标记某个 document 已被删除，那么下次查询的时候则会跳过这个文档，是为逻辑删除。当归并（Merge）的时候，老的 segment 文件将会被删除，合并成新的 segment 文件，这个时候也就是物理删除了。
ES的并发控制
ES通过乐观锁的方式控制并发。ES中的文档是不可变更的，当你更新一个文档时，ES把原来文档标记为删除，增加一个全新的文档，其中version字段加1.
- 内部版本控制
新版ES中通过if_seq_no+if_primary_term的方式完成控制。假设有如下的seq_no = 2, primary_term=2的文档
image.png
如果我们用下面的方式更新文档
PUT /blogs/_doc/1?if_seq_no=0&if_primary_term=1
{
"title": "Quick brown rabbits !!!",
"body": "Brown rabbits are commonly seen."
}
这个时候就会报错。
为什么加一个if_primary_term？
对于if_primary_term记录的就是具体的哪个主分片，而if_seq_no这个参数起的作用和旧版本中的_version是一样的，之所以加上if_primary_term这个参数主要是提高并发的性能以及更自然，因为每个document都只会在某一个主分片中，所以由所在主分片分配序列号比由之前通过一个参数_version，相当于由整个ES集群分配版本号要来的更好。
- 外部版本控制
如果你的ES只是同步外部数据库用作搜索，那么通过version+version_type=external完成并发控制，version可以是存在数据库中的版本号。 下面的例子中有个version=100的文档。
image.png
如果采用下面version小于100的方式更新就会报错
PUT /blogs/_doc/2?version=10&version_type=external
{
"title": "Keeping pets healthy",
"body": "My quick brown fox eats rabbits on a regular basis."
}
