image.png

图示的冲突过程，其实就是es的并发冲突问题，会导致数据不准确。当并发操作es的线程越多，或者读取一份数据，供用户查询和操作的时间越长，在这段时间里，如果数据被其他用户修改，那么我们拿到的就是旧数据，基于旧数据去操作，就会导致错误的结果。

悲观锁&乐观锁

  • 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是并发效率很低，同一时间只能有一条线程操作数据；

  • 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。并发能力很高，不给数据加锁，大量线程并发操作，但是每次更新的时候，都要先比对版本号，然后可能需要更新数据，再次修改，再写；

    es内部乐观锁并发控制思路

    _version概念

    当向es插入一条数据时：

    1. PUT /product/tag_mei_jia/1
    2. {
    3. "name":"天空蓝纯色美甲"
    4. }
    5. //结果
    6. {
    7. "_index": "product",
    8. "_type": "tag_mei_jia",
    9. "_id": "1",
    10. "_version": 1,
    11. "result": "created",
    12. "_shards": {
    13.   "total": 2,
    14.   "successful": 1,
    15.   "failed": 0
    16. },
    17. "created": true
    18. }

    第一次创建document时，它的_version就是1，每次对document进行修改或删除，都会对这个_version进行版本号的加1，哪怕是删除，也会对这条数据的版本号加1操作示例：修改数据两次，然后再删除。

    1. //修改一次
    2. PUT /product/tag_mei_jia/1
    3. {
    4. "name":"天空蓝纯色美甲1"
    5. }
    6. {
    7. "_index": "product",
    8. "_type": "tag_mei_jia",
    9. "_id": "1",
    10. "_version": 2,
    11. "result": "updated",
    12. "_shards": {
    13.   "total": 2,
    14.   "successful": 1,
    15.   "failed": 0
    16. },
    17. "created": false
    18. }
    19. //再修改一次，用post进行修改
    20. POST /product/tag_mei_jia/1/_update
    21. {
    22. "doc":{
    23.   "name":"天空蓝纯色美甲2"
    24. }
    25. }
    26. {
    27. "_index": "product",
    28. "_type": "tag_mei_jia",
    29. "_id": "1",
    30. "_version": 3,
    31. "result": "updated",
    32. "_shards": {
    33.   "total": 2,
    34.   "successful": 1,
    35.   "failed": 0
    36. }
    37. }
    38. //删除，删除后_version也加1了
    39. DELETE /product/tag_mei_jia/1
    40. {
    41. "found": true,
    42. "_index": "product",
    43. "_type": "tag_mei_jia",
    44. "_id": "1",
    45. "_version": 4,
    46. "result": "deleted",
    47. "_shards": {
    48.   "total": 2,
    49.   "successful": 1,
    50.   "failed": 0
    51. }
    52. }

    基于_version的乐观锁并发控制

    每次更新数据时都带上_version参数，_version参数的值必须和更新前查询出来的_version值一致时，才能更新成功（即：先查询当前数据的_version的值，假设为now_1，然后更新时，带上参数_version=now_1去更新）；
    如果_version的版本号不一致的话，此次的更新失败。

    1. //基于上面新插入的数据进行更新，即_version=1，此时更新成功 
    2. PUT /product/tag_mei_jia/1?version=2

    基于external version的乐观锁并发控制

    es提供了一个新特性，就是说，你可以不用基于它提供的内部_version版本号进行并发控制，可以基于自己维护的一个版本号来进行并发控制。

    1. PUT /product/tag_mei_jia/1?version=2&version_type=external

    _version=2和version=2&version_type=external区别

  • _version，只有当你提供的version与es中的_version一模一样的时候，才可以进行修改，只要不一样，就报错；

  • 当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改