1、ElasticSearch源码学习分享：ElasticSearch版本控制

    数据一致性是任何允许多线程对数据作CRUD操作的db系统都绕不过的问题，ElasticSearch也不例外。ElasticSearch提供了版本系统来解决数据的一致性问题。 

    ElasticSearch版本系统的大致思想是：ElasticSearch中存储的每一个document都包含了一个版本号，当用户每次对该document作增删改操作时，ElasticSearch都会对document的版本号进行加1操作。ElasticSearch采用了乐观锁来保证数据的一致性，也就是说，当用户对document进行操作时，并不需要对该document作加锁和解锁的操作，只需要指定要操作的版本即可。当版本号一致时，ElasticSearch会允许该操作顺利执行，而当版本号存在冲突时，ElasticSearch会提示冲突并抛出异常（VersionConflictEngineException异常）。

    以ElasticSearch的内部版本（INTERNAL）为例，当假设当前ElasticSearch中存储了一个verion为10的document。A线程和B线程都获取该document，A线程修改了该document后，将version然后向ElasticSearch发送更新请求，此时，ElasticSearch收到请求后会更新该document，然后将version更新为11。而当B线程修改完document后，将version设为10，然后向ElasticSearch发送更新请求的时候，ElasticSearch会拒绝更新并抛出一个VersionConflictEngineException异常。

   ElasticSearch的版本号的取值范围为1到2^63-1，其中有这么几个特殊值：

   1）当传递给ElasticSearch的版本号为-3时，表示当前的写操作会被强制地写入，不会受当前版本控制的约束。（这里需要注意的是，在1.2以前的版本这个值是0，并且在很长的一段时间，-3和0这两个值是并存的，都表示强制写入。那么当VersionType为INTERNAL时就会出现一种很尴尬的情况，当document不存在时，用户必须将version指定为0才能插入，但是如果遇到之前的例子，A插入之后version变为1，这时候B将version指定为0时依然可以插入成功，这个时候就会覆盖A的操作。好在5.0版本已经把这个蛋疼的常量完全废弃了）

   2）所有不存在的document的version值都为-1（或者说当version为-1时表示这个document不存在）