本文介绍了Elasticsearch中的锁机制，包括乐观锁和悲观锁。乐观锁通过_version进行版本控制，确保并发修改的文档是最新的。悲观锁则通过全局锁、文档锁和树锁实现，类似于数据库中的表锁和行锁，限制了并发操作以保证数据一致性。全局锁对整个index上锁，文档锁针对单个文档，树锁则涉及更细粒度的控制。了解这些锁机制有助于优化Elasticsearch的并发性能。
Elasticsearch和数据库一样，在多线程并发访问修改的情况下，会有一个锁机制来控制每次修改的均为最新的文档。大体上主要有乐观锁和悲观锁两类。
乐观锁
在Elasticsearch通过_version来记录文档的版本，在文档创建时会有一个初始version，默认为1。在对文档进行修改和删除时，version会递增，也可以由用户指定。只有当版本号大于当前版本时，才会修改删除成功，否则失败。当并发请求时，先修改成功的，version会增加，这个时候其他请求就会犹豫version不匹配从而修改失败。
由于segment时不能被修改的，所以当对一个文档执行DELETE之后，在插入相同id的文档，version版本不会是0，而是在DELETE操作的version上递增。
外部版本号和内部版本号区别
对于内在_version=1，只有在后续请求满足?_version=1的时候才能够更新成功；对于外部_version=1，只有在后续请求满足?_version>1才能够修改成功。
es提供了一个外部版本号的乐观控制方案来替代内部的_version。
？version=1&version_type=external
悲观锁
悲观锁类似于数据库中的锁。当线程1在修改或删除doc时，会对数据上锁，这个时候其它线程不能对数据进行操作的。这种方式保证了只有一个线程在同时操作数据。这种方式的缺点是对系统性能有影响，会降低整个系统并发能力
最低0.47元/天 解锁文章
903
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
