ElasticSearch5.5.1(核心7)

最新推荐文章于 2025-09-12 20:46:57 发布

weixin_34265814

最新推荐文章于 2025-09-12 20:46:57 发布

阅读量117

点赞数

CC 4.0 BY-SA版权

文章标签：大数据数据库

原文链接：https://my.oschina.net/mdxlcj/blog/1518738

本文探讨了多线程并发问题，特别是乐观锁与悲观锁的应用场景及其原理。通过具体案例讲解了如何利用Elasticsearch的_version字段实现乐观锁并发控制，以及如何使用externalversion进行外部版本号的并发控制。

为什么80%的码农都做不了架构师？>>>

1、多线程并发问题

如：当你购物，两个人同时浏览一件商品，在手机上显示库存100件，当两人同时购买的时候，会导致多线程并发问题，那么我们怎么解决呢

这个设计到了多线程、乐观锁、悲观锁、以及version的递增

首先讲悲观锁：当我这个线程进行的时候，不会允许其他进程，简单明了说就是我这个人浏览这件商品的时候显示100件，其他人再看这个页面会一直加载数据，等待我这个线程结束才可以，显然悲观锁这个方案是对的。

其次是乐观锁：虽然同时会有多个进程，但是还有一个约束条件就是version，之前我们也讲到了，当document的id没有的时候我们put表示新建，但是如果这个document存在的话，在此基础之上对他修改，那么之前的version=1会发生改变，没进行一次修改，对其加1，乐观锁的时候，首先先要读取数据100件商品，然后多个线程拿到的version=1，一个进程先更新，使得version=2，然后其他的进程都拿着version=1的版本与它匹配，显然是匹配不到了，所以其他进程会重新从es中获取数据，重新获取版本在进行计算。

重点：不管如何，刚刚创建的document的版本version=1，不管是修改删，document的version都会加1，同时删除的话，并不是物理删除，而是当内存达到一定程度下才会删除。

ES内部的内部的多线程异步并发修改时，是基于_version版本号进行乐观锁并发控制的（多个修改请求之间，是乱序没有顺序的，可能后修改的先到）

2、基于external version进行乐观锁并发控制（情况少见）

external version

es提供了一个feature，就是说，你可以不用它提供的内部_version版本号来进行并发控制，可以基于你自己维护的一个版本号来进行并发控制。举个列子，加入你的数据在mysql里也有一份，然后你的应用系统本身就维护了一个版本号，无论是什么自己生成的，程序控制的。这个时候，你进行乐观锁并发控制的时候，可能并不是想要用es内部的_version来进行控制，而是用你自己维护的那个version来进行控制。

?version=1
?version=1&version_type=external

version_type=external，唯一的区别在于，_version，只有当你提供的version与es中的_version一模一样的时候，才可以进行修改，只要不一样，就报错；当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改

2.1先构造一条数据

PUT /test_index/test_type/8
{
"test_field": "test"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "8",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}

2.2 模拟两个客户端同时查询到这条数据

GET /test_index/test_type/8

{
"_index": "test_index",
"_type": "test_type",
"_id": "8",
"_version": 1,
"found": true,
"_source": {
"test_field": "test"
}
}

2.3 第一个客户端先进行修改，此时客户端程序是在自己的数据库中获取到了这条数据的最新版本号，比如说是2

PUT /test_index/test_type/8?version=2&version_type=external
{
"test_field": "test client 1"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "8",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}

2.4 模拟第二个客户端，同时拿到了自己数据库中维护的那个版本号，也是2，同时基于version=2发起了修改

PUT /test_index/test_type/8?version=2&version_type=external
{
"test_field": "test client 2"
}

{
"error": {
"root_cause": [
{
"type": "version_conflict_engine_exception",
"reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
"index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
"shard": "1",
"index": "test_index"
}
],
"type": "version_conflict_engine_exception",
"reason": "[test_type][8]: version conflict, current version [2] is higher or equal to the one provided [2]",
"index_uuid": "6m0G7yx7R1KECWWGnfH1sw",
"shard": "1",
"index": "test_index"
},
"status": 409
}

2.5 在并发控制成功后，重新基于最新的版本号发起更新

GET /test_index/test_type/8

{
"_index": "test_index",
"_type": "test_type",
"_id": "8",
"_version": 2,
"found": true,
"_source": {
"test_field": "test client 1"
}
}

PUT /test_index/test_type/8?version=3&version_type=external
{
"test_field": "test client 2"
}

{
"_index": "test_index",
"_type": "test_type",
"_id": "8",
"_version": 3,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": false
}

转载于:https://my.oschina.net/mdxlcj/blog/1518738