Elasticsearch 并发控制-乐观锁

Elasticsearch 并发控制-乐观锁

一、概述

• 乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
• 悲观锁适用于读比较少的情况下（多写场景），如果是多写的情况，一般会经常产生冲突，如果使 用乐观锁，就会导致上层应用会不断的进行retry（重试），这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

那么ES是选择的哪种方式进行操作的呢？ES选择的乐观锁的方式，因为ES明显属于多读场景，而且一般多读场景的数据是不会需要频繁改动的。

二、乐观锁

在ES的乐观锁中按照常规逻辑，只需要新增一个版本号就可以实现。

PUT /test_index/_doc/7?version=5
{
"test_filed":"test_filed data3"
}

结果报错了。“error” ：验证失败：1:内部版本控制不能用于乐观并发控制。请改用“if-seq-no”和“if-primary_-term”；

官网已经不赞成使用 internal 版本控制进行乐观并发控制，原因是：

• internal 如果主文档发生故障时未完全复制索引文档，则version可能无法唯一标识文档的版本。因此，用于乐观并发控制是不安全的，已弃用，并且该选项在Elasticsearch 7.0.0中将不再可用。请改用 if_seq_no 和 if_primary_term 参数

if_seq_no和if_primary_term

对于if_primary_term记录的就是具体的哪个主分片，而if_seq_no这个参数起的作用和旧版本中的version是一样的。

简单翻译就是为确保较旧版本的文档不会覆盖较新版本，对文档执行的每个操作都会由协调该更改的主分片分配序列号。每次操作都会增加序列号，因此保证较新的操作具有比旧操作更高的序列号。然后，Elasticsearch可以使用序列号操作来确保更新的文档版本永远不会被分配给它的序列号更小的更改覆盖。

PUT /test_index/_doc/7?if_seq_no=1&if_primary_term=1
{
"test_filed":"test_filed data3"
}
现在显示更新成功。

注意当基于最新的数据和版本号，去进行修改，修改后，带上最新的版本号，可能这个步骤会需要反复执行好几次，才能成功，特别是在多线程并发更新同一条数据很频繁的情况下。还有_seq_no，当进行删除操作的时候，seq_no依然会继续增
加，当再次创建的时候它的ID还会再次增加1，seq_no递增属于整个index，而不是单个文档。

三、自定义版本号

能不能自定义版本号呢，替代ES的版本号，可以吗，也就是版本号是存储在自己的数据库中的，可以由开发人员自己控制。
不可以。在6.7版本之后，就移除这个功能，主要是因为：

• 更新API不支持外部或强制版本控制，因为它会导致Elasticsearch版本号与外部系统不同步。