ElasticSearch学习之路-day06

本文转载自:https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html，ES版本号6.3.0

处理冲突
当我们使用 index API 更新文档 ，可以一次性读取原始文档，做我们的修改，然后重新索引 整个文档 。 最近的索引请求将获胜：无论最后哪一个文档被索引，都将被唯一存储在 Elasticsearch 中。如果其他人同时更改这个文档，他们的更改将丢失。
很多时候这是没有问题的。也许我们的主数据存储是一个关系型数据库，我们只是将数据复制到 Elasticsearch并使其可被搜索。也许两个人同时中更改相同的文档的几率很小。或者对于我们的业务来说偶尔丢失更改并不是很严重的问题。
但有时丢失了一个变更就是 非常严重的 。试想我们使用 Elasticsearch 存储我们网上商城商品库存的数量， 每次我们卖一个商品的时候，我们在 Elasticsearch 中将库存数量减少。
有一天，管理层决定做一次促销。突然地，我们一秒要卖好几个商品。 假设有两个 web 程序并行运行，每一个都同时处理所有商品的销售，如图 图 7 “Consequence of no concurrency control” 所示。

web_1 对 stock_count 所做的更改已经丢失，因为 web_2 不知道它的 stock_count 的拷贝已经过期。 结果我们会认为有超过商品的实际数量的库存，因为卖给顾客的库存商品并不存在，我们将让他们非常失望。
变更越频繁，读数据和更新数据的间隙越长，也就越可能丢失变更。
在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：
悲观并发控制
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。一个典型的例子是读取一行数据前先将其锁住，确保只有放置锁的线程能够对这些数据进行修改。
乐观并发控制
Elasticsearch中使用的这种方法是假定冲突时不可能发生的，并且不会阻塞正在尝试的操作。然而如果元数据在读写中被修改，更新将会失败。应用程序接下来决定将如何解决冲突。例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。

乐观并发控制
Elasticsearch是分布式的。当文档创建、更新或删除时，新版本的文档必须复制到集群中的其他节点。Elasticsearch也是异步和并发的，这意味着这些请求被并行发送，并且到达目的地时也许 顺序是乱的。 Elasticsearch 需要一种方法确保文档的旧版本不会覆盖新的版本。
当我们之前讨论 INDEX， GET 和 DELETE请求时，我们指出每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。 Elasticsearch 使用这个 _version 号来确保变更以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。
我们可以利用 _version 号来确保 应用中相互冲突的变更不会导致数据丢失。我们通过指定想要修改文档的 version 号来达到这个目的。 如果该版本不是当前版本号，我们的请求将会失败。

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

响应体告诉我们，这个新创建的文档 _version 版本号是 1 。现在假设我们想编辑这个文档：我们加载其数据到 web 表单中， 做一些修改，然后保存新的版本。
首先我们检索文档:

GET /website/blog/1

响应体包含相同的 _version 版本号 1 ：

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

现在，当我们尝试通过重建文档的索引来保存修改，我们指定 version 为我们的修改会被应用的版本：

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

我们想这个在我们索引中的文档只有现在的 _version 为 1 时，本次更新才能成功。
此请求成功，并且响应体告诉我们 _version 已经递增到 2 ：

{
  "_index": "website",
  "_type": "blog",
  "_id": "1",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}

然而，如果我们重新运行相同的索引请求，仍然指定 version=1 ， Elasticsearch 返回 409 ConflictHTTP 响应码，和一个如下所示的响应体：

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[blog][1]: version conflict, current version [2] is different than the one provided [1]",
        "index_uuid": "g6JAk0OMRsauokdYGafEHA",
        "shard": "3",
        "index": "website"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[blog][1]: version conflict, current version [2] is different than the one provided [1]",
    "index_uuid": "g6JAk0OMRsauokdYGafEHA",
    "shard": "3",
    "index": "website"
  },
  "status": 409
}

这告诉我们在Elasticsearch中这个文档的当前_version是2，但我们指定的更新版本号为1。我们现在怎么做取决于我们的应用需求。我们可以告诉用户说其他人已经修改了文档，并且在再次保存之前检查这些修改内容。或者，在之前的stock_coun场景，我们可以获取到最新的文档并尝试重新应用这些修改。
所有文档的更新或删除API，都可以接受version参数，这允许你在代码中使用乐观的并发控制，这是一种明智的做法。

通过外部系统使用版本控制
一个常见的设置是使用其他数据库作为主要的数据存储，使用Elasticsearch做数据检索，这意味着主数据库的所有更改发生时都需要被复制到Elasticsearh，如果多个进程负责这一数据同步，你可能遇到类似于之前 描述的并发问题。
如果你的主数据库已经有了版本号 — 或一个能作为版本号的字段值比如 timestamp — 那么你就可以在 Elasticsearch 中通过增加 version_type=external 到查询字符串的方式重用这些相同的版本号， 版本号必须是大于零的整数， 且小于 9.2E+18 — 一个 Java 中 long 类型的正值。外部版本号的处理方式和我们之前讨论的内部版本号的处理方式有些不同， Elasticsearch 不是检查当前 _version 和请求中指定的版本号是否相同， 而是检查当前 _version 是否 小于 指定的版本号。 如果请求成功，外部的版本号作为文档的新 _version 进行存储。
外部版本号不仅在索引和删除请求是可以指定，而且在 创建 新文档时也可以指定。
例如，要创建一个新的具有外部版本号 5 的博客文章，我们可以按以下方法进行

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

在响应中，我们能看到当前的 _version 版本号是 5 ：

{
  "_index": "website",
  "_type": "blog",
  "_id": "2",
  "_version": 5,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

现在我们更新这个文档，指定一个新的 version 号是 10 

PUT /website/blog/2?version=10&version_type=external
{
  "title": "My first external blog entry",
  "text":  "This is a piece of cake..."
}

请求成功并将当前 _version 设为 10 ：

{
  "_index": "website",
  "_type": "blog",
  "_id": "2",
  "_version": 10,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}

如果你要重新运行此请求时，它将会失败，并返回像我们之前看到的同样的冲突错误， 因为指定的外部版本号不大于 Elasticsearch 的当前版本号。

文档的部分更新
在 更新整个文档 , 我们已经介绍过 更新一个文档的方法是检索并修改它，然后重新索引整个文档，这的确如此。然而，使用 update API 我们还可以部分更新文档，例如在某个请求时对计数器进行累加。
我们也介绍过文档是不可变的：他们不能被修改，只能被替换。 update API 必须遵循同样的规则。 从外部来看，我们在一个文档的某个位置进行部分更新。然而在内部， update API 简单使用与之前描述相同的 检索-修改-重建索引 的处理过程。 区别在于这个过程发生在分片内部，这样就避免了多次请求的网络开销。通过减少检索和重建索引步骤之间的时间，我们也减少了其他进程的变更带来冲突的可能性。 
update请求最简单的一种形式是接收文档的一部分作为doc参数，他只是与现有的文档进行合并。对象被合并到一起，覆盖现有的字段，增加新的字段。例如，我们增加字段tags和views到我们的博客文档，如下所示:

POST /website/blog/1/_update
{
   "doc" : {
      "tags" : [ "testing" ],
      "views": 0
   }
}

请求成功后的相应:

{
  "_index": "website",
  "_type": "blog",
  "_id": "1",
  "_version": 3,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 2,
  "_primary_term": 1
}

检索文档显示了更新后的 _source 字段：

GET /website/blog/1/_source
{
  "title": "My first blog entry",
  "text": "Just trying this out...",
  "views": 0,
  "tags": [
    "testing"
  ]
}

可以看到views和tags字段已被添加到_source中

使用脚本部分更新文档
脚本可以在 update API中用来改变 _source 的字段内容， 它在更新脚本中称为 ctx._source 。 例如，我们可以使用脚本来增加博客文章中 views 的数量：

POST website/blog/1/_update
{
  "script": "ctx._source.views+=1"
}

返回体

{
  "_index": "website",
  "_type": "blog",
  "_id": "1",
  "_version": 4,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 3,
  "_primary_term": 1
}

我们也可以通过使用脚本给tags数组添加一个新的标签。在这个例子中，我们制定新的标签作为参数，而不是每次我们想添加标签时都要对新脚本重新编译

POST /website/blog/1/_update
{
   "script" : "ctx._source.tags.add(params.new_tag)",
   "params" : {
      "new_tag" : "search"
   }
}

获取文档并显示结果

{
  "_index": "website",
  "_type": "blog",
  "_id": "1",
  "_version": 7,
  "found": true,
  "_source": {
    "title": "My first blog entry",
    "text": "Just trying this out...",
    "views": 1,
    "tags": [
      "testing",
      "search"
    ]
  }
}

可以看到search 标签已追加到 tags 数组中
我们甚至可以选择通过设置 ctx.op 为 delete 来删除基于其内容的文档：

POST /website/blog/1/_update
{
    "script": {
        "source": "ctx.op = ctx._source.views == params.count ? 'delete': 'none'",
        "params": {
            "count": 1
        }
    }
}

更新不存在的文档
想象我们要在Elasticsearch中存储浏览量计数器。每当有用户访问页面，我们增加这个页面的浏览量。但如果这是个新页面，我们并不确定这个计数器存在与否。当我们试图更新一个不存在的文档，更新将失败。
在这种情况下，我们可以使用upsert参数定义文档来使其不存在时被创建。

POST /website/pageviews/1/_update
{
   "script" : "ctx._source.views+=1",
   "upsert": {
       "views": 1
   }
}

第一次执行这个请求,upsert值被索引为一个新文档,初始化views字段为1.接下来文档已经存在,所以script被更新代替,增加views数量。

notes:Elasticsearch6.x不允许索引下有多个文档类型

更新和冲突
这这一节的介绍中，我们介绍了如何在检索(retrieve)和重建索引(reindex)中保持更小的窗口，如何减少冲突性变更发生的概率，不过这些无法被完全避免，像一个其他进程在update进行重建索引时修改了文档这种情况依旧可能发生。
为了避免丢失数据，update API在检索(retrieve)阶段检索文档的当前_version，然后在重建索引(reindex)阶段通过index请求提交。如果其他进程在检索(retrieve)和重建索引(reindex)阶段修改了文档，_version将不能被匹配，然后更新失败。
对于多用户的局部更新，文档被修改了并不要紧。例如，两个进程都要增加页面浏览量，增加的顺序我们并不关心——如果冲突发生，我们唯一要做的仅仅是重新尝试更新既可。
这些可以通过retry_on_conflict参数设置重试次数来自动完成，这样update操作将会在发生错误前重试——这个值默认为0。

POST /website/pageviews/1/_update?retry_on_conflict=5   #在错误发生前重试更新5次
{
   "script" : "ctx._source.views+=1",
   "upsert": {
       "views": 0
   }
}

这适用于像增加计数这种顺序无关的操作，但是还有一种顺序非常重要的情况。例如index API，使用“保留最后更新(last-write-wins)”的update API，但它依旧接受一个version参数以允许你使用乐观并发控制(optimistic concurrency control)来指定你要更细文档的版本。