概要
本篇主要介紹一下Elasticsearch的併發控制和樂觀鎖的實現原理，列舉常見的電商場景，關係型數據庫的併發控制、ES的併發控制實踐。
併發場景
不論是關係型數據庫的應用，還是使用Elasticsearch做搜索加速的場景，只要有數據更新，併發控制是永恆的話題。
當我們使用ES更新document的時候，先讀取原始文檔，做修改，然後把document重新索引，如果有多人同時在做相同的操作，不做併發控制的話，就極有可能會發生修改丟失的。可能有些場景，丟失一兩條數據不要緊（比如文章閱讀數量統計，評論數量統計），但有些場景對數據嚴謹性要求極高，丟失一條可能會導致很嚴重的生產問題，比如電商系統中商品的庫存數量，丟失一次更新，可能會導致超賣的現象。
我們還是以電商系統的下單環節舉例，某商品庫存100個，兩個用戶下單購買，都包含這件商品，常規下單扣庫存的實現步驟
- 客戶端完成訂單數據校驗，準備執行下單事務。
- 客戶端從ES中獲取商品的庫存數量。
- 客戶端提交訂單事務，並將庫存數量扣減。
- 客戶端將更新後的庫存數量寫回到ES。
示例流程圖如下：
如果沒有併發控制，這件商品的庫存就會更新成99（實際正確的值是98），這樣就會導致超賣現象。假定http-1比http-2先一步執行，出現這個問題的原因是http-2在獲取庫存數據時，http-1還未完成下單扣減庫存後，更新到ES的環節，導致http-2獲取的數據已經是過期數據，後續的更新肯定也是錯的。
上述的場景，如果更新操作越是頻繁，併發數越多，讀取到更新這一段的耗時越長，數據出錯的概率就越大。
常用的鎖方案
併發控制尤爲重要，有兩種通用的方案可以確保數據在併發更新時的正確性。
悲觀併發控制
悲觀鎖的含義：我認爲每次更新都有衝突的可能，併發更新這種操作特別不靠譜，我只相信只有嚴格按我定義的粒度進行串行更新，纔是最安全的，一個線程更新時，其他的線程等着，前一個線程更新完成後，下一個線程再上。
關係型數據庫中廣泛使用該方案，常見的表鎖、行鎖、讀鎖、寫鎖，依賴redis或memcache等實現的分佈式鎖，都屬於悲觀鎖的範疇。明顯的特徵是後續的線程會被掛起等待，性能一般來說比較低，不過自行實現的分佈式鎖，粒度可以自行控制（按行記錄、按客戶、按業務類型等），在數據正確性與併發性能方面也能找到很好的折衷點。
樂觀併發控制
樂觀鎖的含義：我認爲衝突不經常發生，我想提高併發的性能，如果真有衝突，被衝突的線程重新再嘗試幾次就好了。
在使用關係型數據庫的應用，也經常會自行實現樂觀鎖的方案，有性能優勢，方案實現也不難，還是挺吸引人的。
Elasticsearch默認使用的是樂觀鎖方案，前面介紹的_version字段，記錄的就是每次更新的版本號，只有拿到最新版本號的更新操作，才能更新成功，其他拿到過期數據的更新失敗，由客戶端程序決定失敗後的處理方案，一般是重試。
ES的樂觀鎖方案
我們還是以上面的案例爲背景，若http-2向ES提交更新數據時，ES會判斷提交過來的版本號與當前document版本號，document版本號單調遞增，如果提交過來的版本號比document版本號小，則說明是過期數據，更新請求將提示錯誤，過程圖如下：
使用內置_version實戰樂觀鎖控制效果
我們在kibana平臺上模擬兩個線程修改同一條document數據，打開兩個瀏覽器標籤即可，我們使用原有的案例數據：
{
"_index": "music",
"_type": "children",
"_id": "2",
"_version": 2,
"found": true,
"_source": {
"name": "wake me, shark me",
"content": "don't let me sleep too late, gonna get up brightly early in the morning",
"language": "english",
"length": "55"
}
}當前的version是2，我們使用一個瀏覽器標籤頁，發出更新請求，把當前的version帶上：
POST /music/children/2?version=2
{
"doc": {
"length": 56
}
}此時更新成功
{
"_index": "music",
"_type": "children",
"_id": "2",
"_version": 3,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 2,
"_primary_term": 2
}同時我們在另一個標籤頁上，也使用version=2進行更新，得到的錯誤結果如下：
{
"error": {
"root_cause": [
{
"type": "version_conflict_engine_exception",
"reason": "[children][2]: version conflict, current version [3] is different than the one provided [2]",
"index_uuid": "9759yb44TFuJSejo6boy4A",
"shard": "2",
"index": "music"
}
],
"type": "version_conflict_engine_exception",
"reason": "[children][2]: version conflict, current version [3] is different than the one provided [2]",
"index_uuid": "9759yb44TFuJSejo6boy4A",
"shard": "2",
"index": "music"
},
"status": 409
}關鍵錯誤信息：version_conflict_engine_exception，版本衝突，將version升到3,模擬失敗後重試，此時更新成功。
真實的場景，重試的次數跟線程併發數有關，線程越多，更新越頻繁，就可能需要重試多次纔可能更新成功。
使用外部_version實戰樂觀鎖控制效果
ES允許不使用內置的version進行版本控制，可以自定義使用外部的version，例如常見的使用Elasticsearch做數據查詢加速的經典方案，關係型數據庫作爲主數據庫，然後使用Elasticsearch做搜索數據，主數據會同步數據到Elasticsearch中，而主數據庫併發控制，本身就是使用的樂觀鎖機制，有自己的一套version生成機制，數據同步到ES那裏時，直接使用更方便。
請求語法上加上version_type參數即可：
POST /music/children/2?version=2&version_type=external
{
"doc": {
"length": 56
}
}唯一的區別
- 內置_version，只有當你提供的version與es中的_version完全一樣的時候，纔可以進行更新，否則報錯；
- 外部_version，只有當你提供的version比es中的_version大的時候，才能完成修改。
Replica Shard數據同步併發控制
在Elasticsearch內部，每當primary shard收到新的數據時，都需要向replica shard進行數據同步，這種同步請求特別多，並且是異步的。如果同一個document進行了多次修改，Shard同步的請求是無序的，可能會出現"後發先至"的情況，如果沒有任何的併發控制機制，那結果將無法相像。
Shard的數據同步也是基於內置的_version進行樂觀鎖併發控制的。
例如Java客戶端向Elasticsearch某條document發起更新請求，共發出3次，Java端有嚴謹的併發請求控制，在ElasticSearch的primary shard中寫入的結果是正確的，但Elasticsearch內部數據啓動同步時，順序不能保證都是先到先得，情況可能是這樣，第三次更新請求比第二次更新請求先到，如下圖：
如果Elasticsearch內部沒有併發的控制，這個document在replica的結果可能是text2，並且與primary shard的值不一致，這樣肯定錯了。
預期的更新順序應該是text1-->text2-->text3，最終的正確結果是text3。那Elasticsearch內部是如何做的呢？
Elasticsearch內部在更新document時，會比較一下version，如果請求的version與document的version相等，就做更新，如果document的version已經大於請求的version，說明此數據已經被後到的線程更新過了，此時會丟棄當前的請求，最終的結果爲text3。
此時的更新順序爲text1-->text3，最終結果也是對的。
小結
本篇主要介紹併發場景出現數據錯亂的原因，Elasticsearch樂觀鎖的實原理，以及ES內部數據同步時的併發控制，有不正確之處或未詳盡之處請知會修改，謝謝。
專注Java高併發、分佈式架構，更多技術乾貨分享與心得，請關注公衆號：Java架構社區
