當並發操作ES的線程越多，或者並發請求越多，或者是讀取一份數據，供用戶查詢和操作的，時間越長，因為這段時間里很可能
數據在ES已經被修改了，那么我們拿到的就是舊的數據，基於舊數據操作，那么后續肯定會出問題
所以我們有悲觀鎖和樂觀鎖倆種並發控制方案
悲觀鎖並發控制方案
常見於關系型數據庫中，比如mysql
悲觀鎖並發控制方案，就是在各種情況下，都上鎖，上鎖之后，就只有一個線程可以操作這一條數據了，當然，不同情況下
上鎖不同（行級鎖，表級鎖，讀鎖，寫鎖）
樂觀鎖控制方案
假設有線程AB
線程B去判斷，當前數據的版本號，version=1，與es中的數據的版本號，version=2，是否相同，明顯是不同的，版本號不同，
說明數據已經被其他人修改過了，此時用戶B不會用99去更新，而是重新去es中讀取最新的數據版本，99件，再次減一，變為
98件，再次執行一下操作就可以
悲觀鎖和樂觀鎖
1. 悲觀鎖的優點：方便，直接加鎖，對應用程序來說，透明，不需要做額外的操作
缺點：並發能力很低，同一時間只能有一條線程操作數據
2. 樂觀鎖的優點是：並發能力很高，不給數據加鎖，大量線程並發操作，
缺點：麻煩，每次更新的時候都要先比對版本號，然后可能需要更新加載數據，再次修改，再寫，這個過程可能要重復好幾次
_version元數據
第一次創建一個document的時候，它的_version內部版本號就是1；以后，每次對這個document執行修改或者刪除操作，都會對
這個_version版本號自動加1；哪怕是刪除
在刪除一個document后，他不是立即物理刪除掉的，因為它的一些版本號等信息還是保留的，先刪除一條document，再重新創建
這條document，其實會在delete version基礎之上，再把version+1
partial update內部會自動執行我們之前所說的樂觀鎖的並發控制政策
retry策略
1. 再次獲取document的數據和最新版本號
2. 基於最新版本號再次去更新，如果成功就ok
3. 如果失敗了，重復1和2倆個步奏，最多重復的次數可以通過retry那個參數的值指定，比如5次