前言
1： 刪除文檔後，版本信息默認會保留60s。
2： 關於cas重試，是需要重新get 一下version的，那肯定會成功吧?這個場景主要在，對於多用戶的局部更新，文檔被修改了並不要緊。例如，兩個進程都要增加頁面瀏覽量，增加的順序我們並不關心——如果衝突發生，我們唯一要做的僅僅是重新嘗試更新既可。
正文
1： ES使用樂觀鎖，即版本號策略來保證數據一致性
PUT /test_index/test_type/6
{
"test_field": "test test"
}
{
"_index": "test_index",
"_type": "test_type",
"_id": "6",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
ES內部維護了version的遞增策略！！！
第一次創建一個document的時候，它的_version內部版本號就是1；以後，每次對這個document執行修改或者刪除操作，都會對這個_version版本號自動加1；哪怕是刪除，也會對這條數據的版本號加1。
注意，在刪除一個document之後，可以從一個側面證明，它不是立即物理刪除掉的，因爲它的一些版本號等信息還是保留着的。先刪除一條document，再重新創建這條document，其實會在delete version基礎之上，再把version號加1.。@hxx，刪除一個文檔後，這個文檔會默認保留60s的版本信息，防止在短時間內的併發更新成功。超過60s後可以隨意更新，夠用了，可以通過index.gc_deletes修改這個閾值。 這個有可能是ttl實現的！