Elasticsearch版本控制

1、为什么要进行版本控制

日常生产环境中，会频繁的对数据进行相关的操作，那么如何保证数据在多线程操作（有两个或两个以上的人在操作修改同一个数据）情况下的准确性，所以就引入了一个版本控制的概念

2、悲观锁和乐观锁

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。

    理解：多线程操作数据的可能性非常大，当一个线程去修改某个数据库的时候，先锁定数据库，只有给这个数据库加了锁的线程，才有权修改数据，等修改完成，解锁，然后其他线程才能进行相关的操作，这种锁机制比较安全，保证数据是准确实时的，悲观锁一般是在并发量很小的情况下使用，如果并发量非常大，使用悲观锁，会造成性能问题，加锁，解锁，会造成性能阻塞

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性（Elasticsearch使用的是乐观锁）

    理解：如果有多个线程正在修改同一条数据，使用乐观锁的结果就是，后面更改数据的线程会更改失败，并且会得到一个错误的返回，后面的这个线程需要再次校验数据，获取数据的最新状态才能更改成功。所以使用乐观锁，会增加大量线程读取数据对象的次数（因为需要不停的刷新、获取数据对象的最新状态，也就是查询会比较多，并且存在读取数据不实时的情况（脏读））

3、内部版本控制和外部版本控制

内部版本控制：

    _version自增长，修改数据后，_version会自动加1

# Version版本控制

PUT /library/books/1

{

    "title": "Elasticsearch": The Definitive Guide",

    "name": {

        "first": "Zachary",

        "last": "Tong"

    },

    "publish_date":"2015-02-06",

    "price":"59.99"

}

GET /library/books/1

POST /library/books/1/_update

{

    "doc": {

        "price": 10

    }

}

#如果你想通过如下方式更新数据，必须保证参数中的version是和document的版本一致，否则报错。

POST /library/books/1/_update?version=3

{

    "doc":{

        "price": 15

    }

}

外部版本控制：

为了保持_version与外部版本控制的数值一致，使用version_type=external检查数据当前的version值是否小于请求中的version值  

    何时使用外部版本控制机制：Elasticsearch的查询非常强大，因此很多系统应用的查询都是交给Elasticsearch的，但是它的主体数据库可能还是传统的关系型数据库，比如oracle，mysql，因此系统开发者，会把oracle或者mysql的数据同步到Elasticsearch当中，而oracle这样的数据库有自己的版本控制机制，比如带有时间戳的字段，数据同步到Elasticsearch之后，希望Elasticsearch也可以使用时间戳的字段进行版本控制，所以就出现了外部版本控制机制。

#外部版本控制

#

PUT /library/books/1?version=5&version_type=external

{

    "title": " Elasticsearch": The Definitive Guide ",

    "name": {

        "first": "Zachary",

        "last": "Tong"

    },

    "publish_date":"2015-02-06",

    "price":"20"     

}

PUT /library/books/1?version=6&version_type=external

{

    "title": "Elasticsearch:The Definitive Guide",

    "name": {

        "first": "Zachary",

        "last":"Tong"

    },

    "publish_date":"2015-02-06",

    "price":"25"

}

GET /library/books/1