ElasticSearch的锁与版本控制

ElasticSearch的版本控制

在使用ES进行文档的更新操作时，会首先读取文档中的原数据，然后更新数据后重新索引该文档，那么无论进行多少次的更新，最后保留的只有最后一份的数据，为了保证更新操作在多线程下的安全性问题，ElasticSearch借助了（乐观）锁来进行版本控制。

ElasticSearch的锁

ElasticSearch使用的是乐观锁，即每次读取数据时都认为别人不会修改数据，只在提交数据时检查数据是否被修改，这种方式相对悲观锁在锁的开销上更小，可以提高吞吐量。

ElasticSearch版本控制

旧版本

在ElasticSearch6.7版本之前，使用的是version+version_type来进行并发控制，version的值是文档之间独立的。每次更新文档，该文档的version就+1，而每次更新时，如果发现先前查询得到的version小于提交时数据中的version，就表示前面的数据已经被更新，此次更新就失效了。

新版本

而在ElasticSearch6.7之后，使用_seq_no与_primary_term来进行版本控制。_seq_no属于整个索引，而不是只属于单一的文档，也就是说每次对索引的任意文档进行更新/新增操作时，索引的_seq_no就会+1（但是要注意的是，虽然索引的_seq_no在不断递增，但是文档中也有一个_seq_no，该文档的_seq_no的值是对他进行最后一次更新后索引的_seq_no值，如果后续不更新，该值并不会改变）

两个判断：

• if_seq_no：表示对要更新文档的_seq_no的期望值
• if_primary_term：表示要更新文档的_primary_term的期望值

// if_seq_no：表示对要更新文档的_seq_no的期望值
// if_primary_term：表示要更新文档的_primary_term的期望值
// 表示文档的_seq_no为11且_primary_term为1时进行更新
PUT blog/_doc/1?if_seq_no=11&if_primary_term=1	
{
  "title":"new new doc"
}

进行实测：

如下：

先更新一个文档

而对其他文档进行一次更新操作后，seq_no增加了1，变成了12：

此时查询文档1，可以看到它的seq_no还是11：

对文档1更新时，必须使用seq_no=11：

更新成功后，被更新文档的seq_no升级到了当前索引的seq_no