Elasticsearch文檔版本沖突原理與解決

一般我們在更新文檔時，主要的操作流程時：讀取文檔->修改->提交保存。數據中心等保存的都是最新一次提交的內容。

大部分時候，這都沒有什么問題。但是如果兩個或更多的請求同時修改一個文檔時，非常容易產生沖突，因為上述的流程無法保證原子性，也不可能保證。
沖突解決常用的兩種策略：

1. 悲觀鎖並發策略
   在關系性數據庫中，通過阻塞並排隊的方式，來避免發生沖突，例如在讀取數據行時阻塞，來保證正在修改行數據的請求完成正常操作后，以讀取到最新的數據。這種方式的前提假設是數據沖突更有可能發生。
2. 樂觀鎖並發策略
   Elasticsearch中采用的是樂觀鎖的並發策略，這種方式的前期假設是數據沖突一般不會發生，從而避免阻塞數據請求。然而，在讀和寫之間，如果數據發生改變，更新就失敗了，然后由程序決定如果進行后續的處理。

　　Elasticsearch是分布式的，文檔的創建/變更等都會同步到其他節點。由於其異步性和並發的特點，這些同步請求都是並行的，因此並不能保證數據的是按照修改順序依次到達的。Elasticsearch保證了一個老版本的數據永遠無法重寫或覆蓋更新版本的數據。在 index get 和 delete請求中，都存在一個 _version 字段。數據的變更均會導致_version的值增大。Elasticsearch通過該字段來保證小於該值的數據會被忽略掉。通過數字版本的方式也可以避免ABA的數據問題，即數據A修改為B而后又修改為A，對於應用端來說，數據是沒有任何變化的。

創建文檔：　

PUT /website/blog/1/_create
{
  "title": "My first blog entry",
  "text":  "Just trying this out..."
}

獲取文檔：

GET /website/blog/1
結果：
{
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "1",
  "_version" : 1,
  "found" :    true,
  "_source" :  {
      "title": "My first blog entry",
      "text":  "Just trying this out..."
  }
}

此時 _version 為1

修改數據：

PUT /website/blog/1?version=1 
{
  "title": "My first blog entry",
  "text":  "Starting to get the hang of this..."
}

{
  "_index":   "website",
  "_type":    "blog",
  "_id":      "1",
  "_version": 2
  "created":  false
}

此時操作成功。

如果在_version為1的基礎我們再次提交修改：

{
   "error": {
      "root_cause": [
         {
            "type": "version_conflict_engine_exception",
            "reason": "[blog][1]: version conflict, current [2], provided [1]",
            "index": "website",
            "shard": "3"
         }
      ],
      "type": "version_conflict_engine_exception",
      "reason": "[blog][1]: version conflict, current [2], provided [1]",
      "index": "website",
      "shard": "3"
   },
   "status": 409
}

此時，顯示存在版本沖突。此時應用可以據此作出相應的處理，獲取最新數據Merge處理亦或其他處理方式。

 

問題解決：在請求上加上retry_on_conflict的參數，在沖突發生時，重試提交數據：

POST /website/pageviews/1/_update?retry_on_conflict=5 
{
   //some update
}