Elasticsearch使用指南（三）运行原理

前言

	这部分的话主要是阅读权威指南以后个人针对es的内部运行原理的梳理和
	学习，其中可能有理解不当也是欢迎支出一起讨论进步。而且这一部分不
	细度也不会影响正常使用，我也仅仅是大致梳理一下，方便日后可以查看

---

    接下来我们来看一下es内部的大致运行原理是怎么样的：

1. 先介绍下各个名称分别代表什么

• cluster 这个主要表示的是es集群，当启动es的时候在conf目录下的elasticsearch.yml配置中，名称相同的话就表示在同一个集群里，组成的话就是由多个节点组成
• node 表示的是节点，也可以认为是一个es的实例，这个与集群共同承担数据和负载的压力
• shard 这个表示的就是分片 作为es的底层工作单元，承担着保存数据的责任，但是一个分片只是保存着一部分的数据，同时一个分片是一个 Lucene 的实例（后面应该会有一个专门描述分片的博客）
  分片的话是分为主分片和副分片两者一对一 数据相同且都能处理搜索请求

2. 我们来看看可以看到的实例情况
   拿之前的内容，先启动一个es实例然后，创建两个索引

http://localhost:9200/_cluster/health?pretty
通过链接可以看到返回的json数据
{
  "cluster_name" : "aze-application",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 2,
  "active_shards" : 2,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 2,
  "delayed_unassigned_shards" : 2,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

这个时候看number_of_nodes表示只有一个节点
然后关注status 是yellow 表示说主分片已经分配 看unassigned_shards
表示有两个副分片是未分配的

---

再看下索引的详情

http://localhost:9200/_cat/indices?v
返回
health status index     uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   customer1 L6i-nqLZQ2edolApiAQaMQ   1   1          4            0      4.4kb          4.4kb
yellow open   user      XodRsihdSsil7jJs9CIm0Q   1   1       1000            0    379.3kb        379.3kb
可以看到 pri 和 rep确实各有一个


http://127.0.0.1:9200/_cat/shards?v 访问这个再看看节点分片的情况
index     shard prirep state      docs   store ip        node
user      0     p      STARTED    1000 379.3kb 127.0.0.1 node-1
user      0     r      UNASSIGNED                        
customer1 0     p      STARTED       4   4.4kb 127.0.0.1 node-1
customer1 0     r      UNASSIGNED            
这下知道了 单节点的话副分片是不起作用的，没法承担起服务容错（一个主分片是对应一个副分片其实数据是一致的）            

---

3. 接下来我们在启动一个实例 看看具体情况
   首先也是先看看集群健康

http://localhost:9200/_cluster/health?pretty
返回
{
  "cluster_name" : "aze-application",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 2,
  "active_shards" : 4,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

这个时候看number_of_nodes已经有2个了
然后关注status 是status 表示说主分片和副分片都已经分配了

再来看下节点分布情况

http://127.0.0.1:9200/_cat/shards?v
index     shard prirep state   docs   store ip        node
user      0     p      STARTED 1000 379.3kb 127.0.0.1 node-1
user      0     r      STARTED 1000 379.3kb 127.0.0.1 node-2
customer1 0     p      STARTED    4   4.4kb 127.0.0.1 node-1
customer1 0     r      STARTED    4   4.4kb 127.0.0.1 node-2

所有分片都被分，可以看出来每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。
后面所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

4. 我们在启动一个实例来看看es对服务故障的处理

http://localhost:9200/_cat/nodes?v  看看节点情况
ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
127.0.0.1           25         100  20    2.65                  cdfhilmrstw -      node-3
127.0.0.1           33         100  14    2.65                  cdfhilmrstw *      node-1
127.0.0.1           16         100  17    2.65                  cdfhilmrstw -      node-2
3个节点 node-1为master节点（带*号）

http://127.0.0.1:9200/_cat/shards?v 看看分片情况
index     shard prirep state   docs   store ip        node
user      0     p      STARTED 1000 379.3kb 127.0.0.1 node-1
user      0     r      STARTED 1000 379.3kb 127.0.0.1 node-3
customer1 0     p      STARTED    4   4.4kb 127.0.0.1 node-1
customer1 0     r      STARTED    4   4.4kb 127.0.0.1 node-2

这样看到主节点上的分片都是主分片
对应的副分片都是在23上
这个时候模拟下主节点挂掉的情况（停掉node-1）

http://localhost:9201/_cat/nodes?v
ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
127.0.0.1           12          99  16    1.91                  cdfhilmrstw -      node-3
127.0.0.1           29          99  16    1.91                  cdfhilmrstw *      node-2
集群必须拥有一个主节点来保证正常工作，所以首先是选举一个主节点
再看看节点情况
http://127.0.0.1:9201/_cat/shards?v
返回
index     shard prirep state   docs   store ip        node
user      0     r      STARTED 1000 379.3kb 127.0.0.1 node-2
user      0     p      STARTED 1000 379.3kb 127.0.0.1 node-3
customer1 0     p      STARTED    4   4.4kb 127.0.0.1 node-2
customer1 0     r      STARTED    4   4.4kb 127.0.0.1 node-3

主分片和副分片正常的分配到对应的节点上

这边要注意的是，当主节点下线的时候健康状态是yellow，因为不会及时的去分配副分片，需要稍微等一会儿

---

考虑es数据量情况，纵向扩容主要的效果是提升数据的存储

技术上来说，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档，但是实际最大值还需要参考你的使用场景：包括你使用的硬件， 文档的大小和复杂程度，索引和查询文档的方式以及你期望的响应时长

从上面的一个操作情况来看的话，我们会发现ElastiSearch天生就是 分布式的，加了节点就会自动分配，然后当节主节点宕机是会自己选举新的主节点，且及时的去创建副分片。

---

			------学习内容来自《Elasticsearch: 权威指南》