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