• A+

Elasticsearch常见问题与解决

当你使用 索引 API来更新一个文档时,我们先看到了原始文档,然后修改它,最后一次性地将整个新文档进行再次索引处理。Elasticsearch会根据请求发出的顺序来选择出最新的一个文档进行保存。但是,如果在你修改文档的同时其他人也发出了指
令,那么他们的修改将会丢失。

       但是有些时候如果我们丢失了数据就会出大问题。想象一下,如果我们使用Elasticsearch来存储一个网店的商品数量。每当我们卖出一件,我们就会将这个数量减少一个。突然有一天,老板决定来个大促销。瞬间,每秒就产生了多笔交易。并行处理,多个进程来处理交易:
       web_1 中 库存量 的变化丢失的原因是 web_2 并不知道它所得到的 库存量 数据是是过期的。这样就会导致我们误认为还有很多货存,最终顾客就会对我们的行为感到失望。
当我们对数据修改得越频繁,或者在读取和更新数据间有越长的空闲时间,我们就越容易丢失掉我们的数据。

 

有两种能避免在并发更新时丢失数据的方法:

悲观并发控制(PCC)

这一点在关系数据库中被广泛使用。假设这种情况很容易发生,我们就可以组织对这一资源的访问。典型的例子就是当我们在读取一个数据前先锁定这一行,然后确保只有读取到数据的这个线程可以修改这一行数据。

乐观并发控制(OCC)

       Elasticsearch所使用的。假设这种情况并不会经常发生,也不会去组织某一数据的访问。然而,如果基础数据在我们读取和写入的间隔中发生了变化,更新就会失败。这时候就由程序来决定如何处理这个冲突。例如,它可以重新读取新数据来进行更新,又或者它可以将这一情况直接反馈给用户。

Elasticsearch是分布式的。当文档被创建、更新或者删除时,新版本的文档就会被复制到集群中的其他节点上。Elasticsearch即是同步的又是异步的,也就是说复制的请求被平行发送出去,然后可能会混乱地到达目的地。这就需要一种方法能够保证新的数据不会被旧数据所覆盖。
       我们在上文提到每当有 索引 、 put 和 删除 的操作时,无论文档有没有变化,它的 _version 都会增加。Elasticsearch使用 _version 来确保所有的改变操作都被正确排序。如果一个旧的版本出现在新版本之后,它就会被忽略掉。
       我们可以利用 _version 的优点来确保我们程序修改的数据冲突不会造成数据丢失。我们可以按照我们的想法来指定_version 的数字。如果数字错误,请求就是失败。

 

我们来创建一个新的博文:

[php] viewplain copy

1.  PUT /website/blog/1/_create  

2.  {  

3.  "title": "My first blog entry",  

4.  "text": "Just trying this out..."  

5.  }  

反馈告诉我们这是一个新建的文档,它的 _version 是 1 。假设我们要编辑它,把这个数据加载到网页表单中,修改完毕然后。

首先我们先要得到文档:

[php] viewplain copy

1.  GET /website/blog/1  

返回结果显示 _version 为 1 :

[php] viewplain copy

1.  {  

2.  "_index" : "website",  

3.  "_type" : "blog",  

4.  "_id" : "1",  

5.  "_version" : 1,  

6.  "found" : true,  

7.  "_source" : {  

8.  "title": "My first blog entry",  

9.  "text": "Just trying this out..."  

10. }  

11. }  

现在,我们试着重新索引文档以保存变化,我们这样指定了 version 的数字:

[php] viewplain copy

1.  PUT /website/blog/1?version=1 <1>  

2.  {  

3.  "title": "My first blog entry",  

4.  "text": "Starting to get the hang of this..."  

5.  }  

1. 我们只希望当索引中文档的_version 是 1 时,更新才生效。请求成功相应,返回内容告诉我们 _version 已经变成了 2 :

[php] viewplain copy

1.  {  

2.  "_index": "website",  

3.  "_type": "blog",  

4.  "_id": "1",  

5.  "_version": 2  

6.  "created": false  

7.  }  

然而,当我们再执行同样的索引请求,并依旧指定 version=1 时,Elasticsearch就会返回一个 409 Conflict 的响应码,返回内容如下:

[php] viewplain copy

1.  {  

2.  "error" : "VersionConflictEngineException[[website][2] [blog][1]:  

3.  version conflict, current [2], provided [1]]",  

4.  "status" : 409  

5.  }  

这里面指出了文档当前的 _version 数字是 2 ,而我们要求的数字是 1 。我们需要做什么取决于我们程序的需求。比如我们可以告知用户已经有其它人修改了这个文档,你应该再保存之前看一下变化。而对于“仓库库存量“问题,我们可能需要重新读取一下最新的文档,然后显示新的数据。所有的有关于更新或者删除文档的API都支持 version 这个参数,有了它你就通过修改你的程序来使用乐观并发控制。

使用外部系统的版本
       还有一种常见的情况就是我们还是使用其他的数据库来存储数据,而Elasticsearch只是帮我们检索数据。这也就意味着主数据库只要发生的变更,就需要将其拷贝到Elasticsearch中。如果多个进程同时发生,就会产生上文提到的那些并发问题。
       如果你的数据库已经存在了版本号码,或者也可以代表版本的 时间戳 。这是你就可以在Elasticsearch的查询字符串后面添加version_type=external 来使用这些号码。版本号码必须要是大于零小于 9.2e+18 (Java中long的最大正值)的整数。
       Elasticsearch在处理外部版本号时会与对内部版本号的处理有些不同。它不再是检查 _version 是否与请求中指定的数值相同,而是检查当前的 _version 是否比指定的数值小。如果请求成功,那么外部的版本号就会被存储到文档中的 _version 中。

例如,创建一篇使用外部版本号为 5 的博文,我们可以这样操作:

[php] viewplain copy

1.  PUT /website/blog/2?version=5&version_type=external  

2.  {  

3.  "title": "My first external blog entry",  

4.  "text": "Starting to get the hang of this..."  

5.  }  

在返回结果中,我们可以发现 _version 是 5 :

[php] viewplain copy

1.  {  

2.  "_index": "website",  

3.  "_type": "blog",  

4.  "_id": "2",  

5.  "_version": 5,  

6.  "created": true  

7.  }  

现在我们更新这个文档,并指定 version 为 10 :

[php] viewplain copy

1.  PUT /website/blog/2?version=10&version_type=external  

2.  {  

3.  "title": "My first external blog entry",  

4.  "text": "This is a piece of cake..."  

5.  }  

请求被成功执行并且 version 也变成了 10 :

[php] viewplain copy

1.  {  

2.  "_index": "website",  

3.  "_type": "blog",  

4.  "_id": "2",  

5.  "_version": 10,  

6.  "created": false  

7.  }  

如果你再次执行这个命令,你会得到之前的错误提示信息,因为你所指定的版本号并没有大于当前Elasticsearch中的版本号。

更新文档中的一部分

       文档不能被修改,它们只能被替换掉。 更新API(update)也必须遵循这一法则。从表边看来,貌似是文档被替换了。对内而言,它必须按照找回-修改-索引的流程来进行操作与管理。不同之处在于这个流程是在一个片(shard) 中完成的,因此可以节省多个请求所带来的网络开销。除了节省了步骤,同时我们也能减少多个进程造成冲突的可能性。
       使用 更新 请求最简单的一种用途就是添加新数据。新的数据会被合并到现有数据中,而如果存在相同的字段,就会被新的数据所替换。

更新和冲突

       在本节的开篇我们提到了当取回与重新索引两个步骤间的时间越少,发生改变冲突的可能性就越小。但它并不能被完全消除,在 更新 的过程中还能可能存在另一个进程进行重新索引的可能性。
       为了避免丢失数据, 更新 API会在获取步骤中获取当前文档中的 _version ,然后将其传递给重新索引步骤中的 索引 请求。如果其他的进程在这两步之间修改了这个文档,那么 _version 就会不同,这样更新就会失败。
       对于很多的局部更新来说,文档有没有发生变化实际上是不重要的。例如,两个进程都要增加页面浏览的计数器,谁先谁后其实并不重要 —— 发生冲突时只需要重新来过即可。你可以通过设定retry_on_conflict 参数来设置自动完成这项请求的次数,它的默认值是 0 。

[php] viewplain copy

1.  POST /website/pageviews/1/_update?retry_on_conflict=5 <1>  

2.  {  

3.  "script" : "ctx._source.views+=1",  

4.  "upsert": {  

5.  "views": 0  

6.  }  

7.  }  

http://blog.csdn.net/huwei2003/article/details/41214391

 

Elasticsearch常见问题收集

 

1 _riverStatus Import_fail 

问题描述:发现有个索引的数据同步不完整,在 http://192.168.1.17:9200/_plugin/head/在browse - river里看到 _riverStatus Import_fail

查看 elasticsearch 的log发现有几条数据由于异常造成同步失败,处理好数据好重新建索引数据同步正常。

2 EsRejectedExecutionException[rejectedexecution (queue capacity 50) on

此异常主要是因为 bulk thead poolset  queue capacity =50 这个可以设置打点

打开 elasticsearch.yml 在末尾加上 

threadpool:
    bulk:
        type: fixed
        size: 60
        queue_size: 1000

重新启动服务即可

另:

--查看线程池设置--
curl -XGET "http://localhost:9200/_nodes/thread_pool/"


类似thread pool设置均可以这样修改
threadpool:
    index:
        type: fixed
        size: 30
        queue_size: 1000

所属分类:问答

全部评论: 0

    我有话说:
    ×