概要

本篇主要介紹一下Elasticsearch的併發控制和樂觀鎖的實現原理，列舉常見的電商場景，關係型資料庫的併發控制、ES的併發控制實踐。

併發場景

不論是關係型資料庫的應用，還是使用Elasticsearch做搜尋加速的場景，只要有資料更新，併發控制是永恆的話題。

當我們使用ES更新document的時候，先讀取原始文件，做修改，然後把document重新索引，如果有多人同時在做相同的操作，不做併發控制的話，就極有可能會發生修改丟失的。可能有些場景，丟失一兩條資料不要緊（比如文章閱讀數量統計，評論數量統計），但有些場景對資料嚴謹性要求極高，丟失一條可能會導致很嚴重的生產問題，比如電商系統中商品的庫存數量，丟失一次更新，可能會導致超賣的現象。

我們還是以電商系統的下單環節舉例，某商品庫存100個，兩個使用者下單購買，都包含這件商品，常規下單扣庫存的實現步驟

1. 客戶端完成訂單資料校驗，準備執行下單事務。
2. 客戶端從ES中獲取商品的庫存數量。
3. 客戶端提交訂單事務，並將庫存數量扣減。
4. 客戶端將更新後的庫存數量寫回到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架構社群

相關推薦