elastic 部分更新 retry_on_conflict 和 数据库写锁 详细比对

Posted cxygg

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了elastic 部分更新 retry_on_conflict 和 数据库写锁 详细比对相关的知识,希望对你有一定的参考价值。

1 数据库的  update 在修改这条数据的的过程中(这个过程指的是 数据库执行update 到 事务提交的过程中 )为这条数据加上 写锁,阻止 别的事务 对锁定数据的修改,请求后一个修改事务的线程阻塞,直到前一个事务的完成,所以针对这条数据的 2 个修改 是一个一个来的。所以 数据库的  update t1 set a = a+1; 这样的操作 不会导致 a数据的 丢失,因为前一个事务 执行的时候回阻塞后一个事务提交数据。  但是 如果先查询出a=1, 然后 a =  1(这个1 是查询到的 a)+1 ;这样的操作会 丢失 a ,因为 a 两个事务查询的a 可能 会被修改了。

 

2, es 的 全部修改,如果没有带上 version的 时候,直接替换原来的 文档,没有查询的过程。多线程操作,不区分执行的先后顺序。 但是带上version的时候 version 表示先后顺序。先执行成功的为主,后来的不合法被舍弃(抛出异常)。

 

3,  es 部分修改的时候,修改请求到达 es 的 时候,es会在内部查询 一下原理的文档,然后执行 ,部分更新,注意一下,这时候 是 es 并不阻止 别的线程修改 这条数据,可能这个es 内部的查询 同是有多个( 这个阶段叫做 retrieve ),检索完成 记录一下 这是的                    version,  和传过来的新的数据一起生成新的文档,然后把旧的文档改成假删除(这个过程叫做  reindex),这时候会修改 set version=version  and version = version,如果另一个 线程做着同样的操作并且慢了 一点点,重建 索引这步 就会出异常。这时候 es会 重             复检索和 重构索引的过程 知道 正常完成 或者 重试次数大于 retry_on_conflict 抛出异常。

  es 会吧 原理的就文档

 

总结:数据库 拒绝 第二个事务来修改 已经被修改但是未被提交的数据(事务未提交)。 es 的全更新  不会有自动检索 的过程,直接替换,可以通过version 控制并发。部分更新有自动检索的过程 ,并发修改冲突会重新检索,带上version然后重新新构建索引

   重试 retry_on_conflict  次后会抛出异常,并且 也可以通过 version 控制(retry_on_conflict   默认0 次 相当于 自动带上了version,但是不完成等价 , 因为 version 读的 时机 不同,有些情况可能 不同的结果,主要肯写法 和 业务 情景 比如 a = a+1  就没影响,但是 a =           1+1  就有影响,可以细细体会 一下,挺有意思的 )。

以上是关于elastic 部分更新 retry_on_conflict 和 数据库写锁 详细比对的主要内容,如果未能解决你的问题,请参考以下文章

elastic 部分更新 retry_on_conflict 和 数据库写锁 详细比对

json elastic:获取SiteMinder配额更新

Elastic Beanstalk 滚动环境配置更新

使用 terraform 为 Elastic Beanstalk 启用托管更新

Elastic search集群新增节点(同一集群,同一 物理机)

Elastic Beanstalk 无法更新本地 Git 配置