一、什么是并发问题
二、悲观锁&&乐观锁
ES采取的是乐观锁机制
三、ES是如何解决并发问题的?
ES是靠内部维护的一个_version版本号字段进行乐观锁的。
比如我们PUT一条document到ES
PUT /test_index/_doc/1
{
"test_field" : "test test"
}
返回结果
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}
这里可以看到_version是1,因为是刚created,我们修改一下再来看看
进行修改这条数据,再次看_version字段:
PUT /test_index/_doc/1
{
"test_field" : "abc 123"
}
返回结果
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "1",
"_version" : 2,
"result" : "updated",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1
}
可以看到_version变成2了。
补充个知识点:
我们删除id=1的document,再看_version
DELETE /test_index/_doc/1
返回结果:
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "1",
"_version" : 3,
"result" : "deleted",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 2,
"_primary_term" : 1
}
_version再次+1了,奇怪,删除怎么还+1? 我们再PUT试试
再次PUT id=1的document
PUT /test_index/_doc/1
{
"test_field" : "abc 123"
}
返回结果
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "1",
"_version" : 4,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 3,
"_primary_term" : 1
}
神奇的事情发现了,我们delete掉了,再次PUT的时候_version居然是4而不是1,所以这里引入一个知识点:
他不是立即物理删除的,因为他的一些版本号等信息还是保留着的。先删除一条document,再重新创建这条document,其实会在delete version基础之上,再把version号加1
四、实战演示乐观锁
(1)先构造一条数据
PUT /test_index/test_type/3
{
"test_field" : "test test"
}
(2)新开个浏览器网页,输入Kibana网址,打开两个Kibana客户端,模拟两个客户端,都获取到了同一条数据
GET /test_index/test_type/3
两个客户端都返回
{
"_index": "test_index",
"_type": "test_type",
"_id": "3",
"_version": 1,
"found": true,
"_source": {
"test_field": "test test"
}
}
(3)其中一个客户端,先更新了一下这条数据同时带上版本号,es中的数据的版本号跟客户端中的数据的版本号是相同的才能修改,否则视为并发冲突。
PUT /test_index/test_type/3?version=1
{
"test_field" : "test client one"
}
结果
{
"_index": "test_index",
"_type": "test_type",
"_id": "3",
"_version": 2,
"result": "updated",
"_shards": {
"total": 5,
"successful": 1,
"failed": 0
},
"created": false
}
结果可看到数据变了,此时版本号是2
(4)另一个客户端,尝试基于version=1的数据进行修改,同样带上version=1(模拟并发请求),进行乐观锁的并发控制
PUT /test_index/test_type/3?version=1
{
"test_field" : "test client two"
}
结果:
{
"error": {
"root_cause": [
{
"type": "version_conflict_engine_exception",
"reason": "[test_type][3]: version conflict, current version [2] is different than the one provided [1]",
"index_uuid": "ey5OuEyFTHe7QhJUvcLDXQ",
"shard": "2",
"index": "test_index"
}
],
"type": "version_conflict_engine_exception",
"reason": "[test_type][3]: version conflict, current version [2] is different than the one provided [1]",
"index_uuid": "ey5OuEyFTHe7QhJUvcLDXQ",
"shard": "2",
"index": "test_index"
},
"status": 409
}
版本冲突,当前版本是2,要改的1,找不到version=1的数据
(5)在乐观锁成功阻止并发问题之后,尝试正确的完成更新
GET /test_index/test_type/3
返回结果:
{
"_index": "test_index",
"_type": "test_type",
"_id": "3",
"_version": 2,
"found": true,
"_source": {
"test_field": "test client one"
}
}
基于最新的数据和版本号,去进行修改,修改后,带上最新的版本号(这个步骤可能会需要反复执行好几次才能成功,主要看并发量多少)
PUT /test_index/test_type/3?version=2
{
"test_field" : "test client two"
}
结果:
{
"_index": "test_index",
"_type": "test_type",
"_id": "3",
"_version": 3,
"result": "updated",
"_shards": {
"total": 5,
"successful": 1,
"failed": 0
},
"created": false
}
此时version变成了3。
微信公众号