Elasticsearch技术解析与实战（六）Elasticsearch并发
乐观锁与悲观锁
图示的冲突过程，其实就是es的并发冲突问题，会导致数据不准确
当并发操作es的线程越多，或者读取一份数据，供用户查询和操作的时间越长，在这段时间里，如果数据被其他用户修改，那么我们拿到的就是旧数据，基于旧数据去操作，就会导致错误的结果
- 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
- 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
- 两者之间的优缺点
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是并发效率很低，同一时间只能有一条线程操作数据
悲观锁并发能力很高，不给数据加锁，大量线程并发操作，但是每次更新的时候，都要先比对版本号，然后可能需要更新数据，再次修改，再写
Elasticsearch内部基于_version进行乐观锁并发控制
1.构造一条数据出来
PUT /test_index/test_type/7
{
"test_field": "test test"
}
2.模拟两个客户端，都获取到了同一条数据，其中一个客户端，先更新了一下这个数据
同时带上数据的版本号，确保说，es中的数据的版本号，跟客户端中的数据的版本号是相同的，才能修改
PUT /test_index/test_type/7?version=1
{
"test_field": "test client 1"
}
3.另外一个客户端，尝试基于version=1的数据去进行修改，同样带上version版本号，进行乐观锁的并发控制
PUT /test_index/test_type/7?version=1
{
"test_field": "test client 2"
}
4.基于最新的数据和版本号，去进行修改，修改后，带上最新的版本号，可能这个步骤会需要反复执行好几次，才能成功，特别是在多线程并发更新同一条数据很频繁的情况下
PUT /test_index/test_type/7?version=2
{
"test_field": "test client 2"
}
基于external version进行乐观锁并发控制
es提供了一个新特性，就是说，你可以不用基于它提供的内部_version版本号进行并发控制，可以基于自己维护的一个版本号来进行并发控制。
参数写法
？version=1&version_type=external
？version=1和？version=1&version_type=external的区别
_version，只有当你提供的version与es中的_version一模一样的时候，才可以进行修改，只要不一样，就报错；
当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改
1.先构造一条数据
PUT /test_index/test_type/8
{
"test_field": "test"
}
2.模拟两个客户端同时查询到这条数据，第一个客户端先进行修改，此时客户端程序是在自己的数据库中获取到了这条数据的最新版本号，比如说是2
PUT /test_index/test_type/8?version=2&version_type=external { "test_field": "test client 1" }
3.模拟第二个客户端，同时拿到了自己数据库中维护的那个版本号，也是2，同时基于version=2发起了修改
PUT /test_index/test_type/8?version=2&version_type=external { "test_field": "test client 2" }
4.在并发控制成功后，重新基于最新的版本号发起更新
PUT /test_index/test_type/8?version=3&version_type=external { "test_field": "test client 2" }
