Elastic Search 分布式架构分析

1 ES分布式机制的透明隐藏特性
ES本身就是一个分布式系统，就是为了处理海量数据的应用。ES隐藏了复杂的分布式机制，简化了配置和操作的复杂度。ES在现在的互联网环境中，盛行的原因，主要的核心就是分布式的简化。
ES隐藏的内容：分片机制、集群发现机制（cluster discovery）、shard负载均衡、shard副本、请求路由、集群扩容、shard重分配等。
如：分片机制-shard， 主分片 primary shard。不管多少个节点，也不管index创建的时候，分多少个primary shard，是否需要管理哪一个节点管理哪些shard？
如：shard负载均衡，在读写操作的时候，是否考虑过，本次操作在哪一个shard上执行？

2 ES的扩容
什么水平扩容？什么是垂直扩容？
水平扩容：就是如果资源不足的时候，添加新的资源。如：服务器能力不足，买新服务器，存储不足，买新的服务器。
垂直扩容：如果资源不足的时候，优化资源。如：服务器能力不足，替换新的更强的服务器。

2.1 水平扩容
增加新的集群节点，实现扩容。水平扩容方案使用的频率更高。

2.2 垂直扩容
替换集群节点硬件配置。在节点数量不变的情况下，实现扩容逻辑。垂直扩容有硬件瓶颈，且成本过高，相对使用的更少。

3 节点变化时的数据rebalance
在节点发生变化时，ES的cluster会自动调整每个节点中的数据，也就是shard的重新分配。这个过程就是rebalance。ES做rebalance，目的是为了提高性能。理论上，当数据量达到一定级别的时候，每个shard分片上的数据量是均等的。那么每个节点管理的shard数量是均等的情况，ES集群才能提供最好的服务性能。

4 master节点作用
现在不是讲如何配置master，是讲解master的功能。讲解master概念。
维护集群元数据的节点。如：索引的变更（创建和删除），对应的元数据保存在master节点中。
集群在默认配置中，会自动的选举出master节点。
master不是请求的唯一接收节点。只是维护元数据的特殊节点。不会导致单点瓶颈。
元数据是一个收集管理的过程。不是一个必要的不可替代的数据。Master如果宕机，集群会选举出新的master，新的master会在集群的所有节点中重新收集集群元数据并管理。

5 节点平等的分布式架构
节点平等 - 每个节点都能接收客户端请求。不会造成单点压力
自动请求路由 - 节点在接收到客户端请求时，会自动的识别应该由哪个节点处理本次请求，并实现请求的转发。
响应收集 - 在自动请求路由后，接收客户端请求的节点会自动的收集其他节点的处理结果，并统一响应给客户端。

6 并发冲突
ES是一个分布式的集群应用，是处理高并发环境的应用。有高并发，就可能有并发冲突问题。
如电商系统中的商品库存更新问题。

6.1 悲观锁
一般是关系型数据库中使用。控制并发执行数量。让每个单位时间中，只有一个线程控制一条数据。如：表级锁，行级锁，读锁，写锁等。

6.2 乐观锁
基于版本（时间戳）实现的数据控制方式。也就是在对数据实现写操作时，必须保证被修改数据的版本（时间戳）与读取时的版本（时间戳）完全一致。常使用于关系型数据库、分布式数据存储应用、数据缓存服务器等。在ES中通常使用乐观锁机制控制并发访问冲突问题。
select xxx from table where xxxxxxx
update table set xxx=new_value, version = new_version where id=? and version=上一次查询到的数据

6.2.1 测试内置_version
案例数据：

GET products_index/phone_type/1

{
  "_index": "products_index",
  "_type": "phone_type",
  "_id": "1",
  "_version": 1, # 元数据 version。 版本信息。 默认是ES控制。每次写操作，版本自增1。删除也是写操作。
  "found": true,
  "_source": {
    "name": "IPHONE 8",
    "remark": "64G",
    "price": 548800,
    "producer": "APPLE",
    "tags": [
      "64G",
      "red color",
      "Nano SIM"
    ]
  }
}

　　

全量替换（乐观锁）：乐观锁的使用，就是通过参数version。ES会检查请求中的version和存储中的version是否相等。如果不相等报错，如果相等，修改。

PUT /products_index/phone_type/1?version=2
{
  "name" : "iphone x",
  "remark" : "256G",
  "price" : 899900,
  "producer" : "apple",
  "tags" : [ "256G" ]
}

　　

6.2.2 测试external version
ES提供了一个feature，就是可以自定义version实现ES内置的_version元数据版本管理功能。与元数据_version的区别是：元数据比对必须完全一致；而external version必须比元数据_version数据大。
external version版本控制特点：要求提供的version数据必须比元数据_version大。在更新成功后，ES中记录的元数据_version修改为提供的external version数据值。
案例数据：

GET products_index/phone_type/1

{
  "_index": "products_index",
  "_type": "phone_type",
  "_id": "1",
  "_version": 3,
  "found": true,
  "_source": {
    "name": "iphone x",
    "remark": "256G",
    "price": 899900,
    "producer": "apple",
    "tags": [
      "256G"
    ]
  }
}

　　

元数据_version修改：

PUT /products_index/phone_type/1?version=3
{
  "name" : "iphone x",
  "remark" : "256G",
  "price" : 899900,
  "producer" : "apple",
  "tags" : [ "256G" ]
}

　　

external version修改：

PUT /products_index/phone_type/1?version=5&version_type=external
{
  "name" : "iphone x",
  "remark" : "256G",
  "price" : 899900,
  "producer" : "apple",
  "tags" : [ "256G" ]
}

　　

6.2.3 测试partial update乐观锁
在ES中，使用partial update更新数据时，ES内部自动使用乐观锁控制数据的并发安全。如果出现数据冲突（版本不一致）的时候，ES会提示更新失败。可以通过命令中的参数实现手工管理乐观锁。在ES中，retry_on_conflict和version参数不能同时使用。因为ES中的partial update本身自带乐观锁控制。所以，如果再传递一个version参数，是有底层控制冲突的。
使用参数retry_on_conflict，自动重试多次，实现乐观锁控制。

POST /products_index/phone_type/1/_update?retry_on_conflict=3
{
  "doc": {
    "price" : 2999900
  }
}

　　

使用参数version，指定版本的乐观锁控制

POST /products_index/phone_type/1/_update?version=5
{
  "doc": {
    "price" : 999900
  }
}