當併發操作es的執行緒越多，或者併發請求越多，或者是讀取乙份資料，供使用者查詢和操作的，時間越長，因為這段時間裡很可能
資料在es已經被修改了，那麼我們拿到的就是舊的資料，基於舊資料操作，那麼後續肯定會出問題
所以我們有悲觀鎖和樂觀鎖倆種併發控制方案
悲觀鎖併發控制方案
常見於關係型資料庫中，比如mysql
悲觀鎖併發控制方案，就是在各種情況下，都上鎖，上鎖之後，就只有乙個執行緒可以操作這一條資料了，當然，不同情況下
上鎖不同（行級鎖，表級鎖，讀鎖，寫鎖）
樂觀鎖控制方案
假設有執行緒ab
執行緒b去判斷，當前資料的版本號，version=1，與es中的資料的版本號，version=2，是否相同，明顯是不同的，版本號不同，
說明資料已經被其他人修改過了，此時使用者b不會用99去更新，而是重新去es中讀取最新的資料版本，99件，再次減一，變為
98件，再次執行一下操作就可以
悲觀鎖和樂觀鎖
1. 悲觀鎖的優點：方便，直接加鎖，對應用程式來說，透明，不需要做額外的操作
缺點：併發能力很低，同一時間只能有一條執行緒運算元據
2. 樂觀鎖的優點是：併發能力很高，不給資料加鎖，大量執行緒併發操作，
缺點：麻煩，每次更新的時候都要先比對版本號，然後可能需要更新載入資料，再次修改，再寫，這個過程可能要重複好幾次
_version元資料
第一次建立乙個document的時候，它的_version內部版本號就是1；以後，每次對這個document執行修改或者刪除操作，都會對
這個_version版本號自動加1；哪怕是刪除
partial update內部會自動執行我們之前所說的樂觀鎖的併發控制政策
retry策略
1. 再次獲取document的資料和最新版本號
2. 基於最新版本號再次去更新，如果成功就ok
3. 如果失敗了，重複1和2倆個步奏，最多重複的次數可以通過retry那個引數的值指定，比如5次
ES處理衝突
1 什麼是文件 物件json序列化後是乙個文件2 如何唯一確定乙個文件 index type id id可以由外部指定，也可以由es自動生成3 es更新文件流程 先get原始文件，然後修改，最後將整個文件進行再次索引處理4 es中 version變更 對應於增刪查改操作，es中索引 put和刪除操作...
使用forupdate解決併發衝突
任務場景 有乙個主任務表，然後有個子任務表，乙個主任務對應多個子任務 當所有子任務完成的時候，需要去更新主任務表為完成狀態。其中過程為，更新子任務，查詢剩餘子任務數量，如果剩餘子任務數量為0，則更新主任務狀態。併發問題就是 如果最後剩兩個使用者，他們提交子任務時後，去查詢剩餘子任務數量，因為開啟了事...
msvcprt lib 衝突的問題
exe呼叫lib編譯出錯 3 hm2p5datastructure.lib datastructurein.obj msil netmodule or module compiled with gl found restarting link with ltcg add ltcg to the li...