ElasticSearch 并发的处理方式：锁和版本控制

松哥原创的 Spring Boot 视频教程已经杀青，感兴趣的小伙伴戳这里-->Spring Boot+Vue+微人事视频教程

ElasticSearch 系列第九篇，和大家聊一聊索引的基本操作，前八篇传送门：

1. 打算出一个 ElasticSearch 教程，谁赞成，谁反对？
   
2. ElasticSearch 从安装开始
   
3. ElasticSearch 第三弹，核心概念介绍
   
4. ElasticSearch 中的中文分词器该怎么玩？
   
5. ElasticSearch 索引基本操作
   
6. ElasticSearch 文档的添加、获取以及更新
   
7. ElasticSearch 文档的删除和批量操作
   
8. ElasticSearch 文档路由，你的数据到底存在哪一个分片上？
   

以下是视频笔记：

注意，笔记只是视频内容的一个简要记录，因此笔记内容比较简单，完整的内容可以查看视频。

当我们使用 es 的 API 去进行文档更新时，它首先读取原文档出来，然后对原文档进行更新，更新完成后再重新索引整个文档。不论你执行多少次更新，最终保存在 es 中的是最后一次更新的文档。但是如果有两个线程同时去更新，就有可能出问题。

要解决问题，就是锁。

8.1 锁

悲观锁

很悲观，每一次去读取数据的时候，都认为别人可能会修改数据，所以屏蔽一切可能破坏数据完整性的操作。关系型数据库中，悲观锁使用较多，例如行锁、表锁等等。

乐观锁

很乐观，每次读取数据时，都认为别人不会修改数据，因此也不锁定数据，只有在提交数据时，才会检查数据完整性。这种方式可以省去锁的开销，进而提高吞吐量。

在 es 中，实际上使用的就是乐观锁。

8.2 版本控制

es6.7之前

在 es6.7 之前，使用 version+version_type 来进行乐观并发控制。根据前面的介绍，文档每被修改一个，version 就会自增一次，es 通过 version 字段来确保所有的操作都有序进行。

version 分为内部版本控制和外部版本控制。

8.2.1 内部版本

es 自己维护的就是内部版本，当创建一个文档时，es 会给文档的版本赋值为 1。

每当用户修改一次文档，版本号就回自增 1。

如果使用内部版本，es 要求 version 参数的值必须和 es 文档中 version 的值相当，才能操作成功。

8.2.2 外部版本

也可以维护外部版本。

在添加文档时，就指定版本号：

PUT blog/_doc/1?version=200&version_type=external
{
  "title":"2222"
}

以后更新的时候，版本要大于已有的版本号。

• vertion_type=external 或者 vertion_type=external_gt 表示以后更新的时候，版本要大于已有的版本号。
  
• vertion_type=external_gte 表示以后更新的时候，版本要大于等于已有的版本号。
  

8.2.3 最新方案（Es6.7 之后）

现在使用 if_seq_no 和 if_primary_term 两个参数来做并发控制。

seq_no 不属于某一个文档，它是属于整个索引的（version 则是属于某一个文档的，每个文档的 version 互不影响）。现在更新文档时，使用 seq_no 来做并发。由于 seq_no 是属于整个 index 的，所以任何文档的修改或者新增，seq_no 都会自增。

现在就可以通过 seq_no 和 primary_term 来做乐观并发控制。

PUT blog/_doc/2?if_seq_no=5&if_primary_term=1
{
  "title":"6666"
}