最终一致性的常用做法

标签: 一致性 | 发表时间:2018-12-01 22:28 | 作者:huangyongxing310
出处:http://www.iteye.com
最终一致性的常用做法

1、单数据库事务
利用数据库的事务特性来满足事务的一致性,这时候的一致性是强一致性的。


2、多数据库事务
针对多数据库事务可以根据二阶段提交协议,采用spring 3.0 + Atomikos + JTA进行支持;


3、基于事务型消息队列的最终一致性
借助消息队列,在处理业务逻辑的地方发送消息,业务逻辑处理成功后,提交消息,确保消息是发送成功的,之后消息队列投递来进行处理,如果成功,则结束,如果没有成功,则重试,直到成功,不过仅仅适用业务逻辑中,第一阶段成功,第二阶段必须成功的场景。


4、基于消息队列+定时补偿机制的最终一致性
前面部分和上面基于事务型消息的队列,不同的是,第二阶段重试的地方,不再是消息中间件自身的重试逻辑了,而是单独的补偿任务机制。其实在大多数的逻辑中,第二阶段失败的概率比较小,所以单独独立补偿任务表出来,可以更加清晰,能够比较明确的直到当前多少任务是失败的。对应上图的E流程。


5、异步回调机制的引入
A应用调用B,在同步调用的返回结果中,B返回成功给到A,一般情况下,这时候就结束了,其实在99.99%的情况是没问题的,但是有时候为了确保100%,记住最起码在系统设计中100%,这时候B系统再回调A一下,告诉A,你调用我的逻辑,确实成功了。其实这个逻辑,非常类似TCP协议中的三次握手。


6、类似double check机制的确认机制
A在同步调用B,B返回成功了。这次调用结束了,但是A为了确保,在过一段时间,这个时间可以是几秒,也可以是每天定时处理,再调用B一次,查询一下之前的那次调用是否成功。例如A调用B更新订单状态,这时候成功了,延迟几秒后,A查询B,确认一下状态是否是自己刚刚期望的。



分布式事务的缺点
1、二阶段提交协议缺点
两阶段提交涉及到多个节点的网络通信,通信时间如果过长,事务的相对时间也就会过长,那么锁定资源的时间也就长了.在高并发的服务中,就会存在严重的性能瓶劲,也不一定可以保证一致性


2、消息队列
在高并发的环境中,我们一般会采用消息队列来避免分布式事务的执行。
在使用消息队列时,我们需要做到可靠凭证的保存(分布式事务的消息),有如下几种方式:
以支付宝和余额宝为例进行说明.
支付宝完成扣钱的动作时,记录消息数据,将消息数据和业务数据存在同一个数据库实例中.(同一个库保证了一致性)

将支付宝完成扣钱的消息及时发送给余额宝,余额宝完成处理后返回成功消息,支付宝收到消息后,消除消息表中对应的消息记录,即完成本次扣钱操作.




//=========================================
MQ也可以在另一个线程中进行发送,发送成功后就删除,就算删除不成功也没问题,大不了多发了一个消息。


为了确保消息的安全性,可以在发送端保存消息,更改状态表示消息已经发送了,通过消费端的回复再确认消息已经消费成功了就更安全了(防止MQ的数据丢失)
当然确保消息一定发送出去也是要确保才行



https://blog.csdn.net/zxl315/article/details/53433707(分布式事务最终一致性常用方案)

https://blog.csdn.net/qq_27384769/article/details/79305402(分布式事务)




































已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [一致性] 推荐:

一致性hash

- - 互联网 - ITeye博客
一致性hash算法 - consistent hashing. 分类:  算法艺术2010-02-02 09:19 69836人阅读  评论(97)  收藏  举报. 算法 cache object 服务器 存储 c. 一致性 hash 算法( consistent hashing ).

大数据的一致性

- - 阳振坤的博客
看到了一篇关于数据一致性的文章:下一代NoSQL:最终一致性的末日. (  http://www.csdn.net/article/2013-11-07/2817420 ),其中说到: 相比关系型数据库,NoSQL解决方案提供了shared-nothing、容错和可扩展的分布式架构等特性,同时也放弃了关系型数据库的强数据一致性和隔离性,美其名曰:“最终一致性”.

COMMIT和数据一致性

- - Oracle - 数据库 - ITeye博客
[align=justify; direction: ltr; unicode-bidi: embed; vertical-align: baseline;]2.在执行一条update语句后一直未提交,数据会写到数据文件中吗. 一致性查询及一致性读原理. 如果8点钟可以查询出两条记录,假设一下,如果此查询很慢,从8点开.

一致性HASH算法

- - 企业架构 - ITeye博客
一致性 hash 算法( consistent hashing ). consistent hashing 算法早在 1997 年就在论文 . Consistent hashing and random trees 中被提出,目前在cache 系统中应用越来越广泛;. 比如你有 N 个 cache 服务器(后面简称 cache ),那么如何将一个对象 object 映射到 N 个 cache 上呢,你很可能会采用类似下面的通用方法计算 object 的 hash 值,然后均匀的映射到到 N 个 cache ;.

一致性Hash算法背景(转)

- - 开源软件 - ITeye博客
一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似. 一致性哈希修正了CARP使用的简单哈希算法带来的问题,使得DHT可以在P2P环境中真正得到应用.   但现在一致性hash算法在分布式系统中也得到了广泛应用,研究过memcached缓存数据库的人都知道,memcached服务器端本身不提供分布式cache的一致性,而是由客户端来提供,具体在计算一致性hash时采用如下步骤:.

一致性hash算法测试

- - Java - 编程语言 - ITeye博客
package com.xll; //服务器对象 public class Server {. private void init() { // 初始化一致性hash环. for (int i = 0; i != servers.size(); ++i) { // 每个真实机器节点都需要关联虚拟节点.

一致性哈希算法 - Consistent Hashing

- - CSDN博客云计算推荐文章
一、简单介绍一致性哈希算法.         分布式存储中,常常涉及到负载均衡问题,由于有多个数据存储服务器. 因此当一个对象被保存时候,它究竟应该存放到哪个数据存储服务器上面呢.         又例如:现在假设有一个网站,最近发现随着流量增加,服务器压力越来越大,之前直接读写数据库的方式已经不能满足用户的访问,于是想引入 Memcached 作为缓存机制.

一致性哈希算法(consistent hashing)

- - 互联网 - ITeye博客
consistent hashing由来. 在麻省理工学院用作分布式缓存,现在已经扩大到其他领域. 它被设计来解决hash的什么问题. 假设有m个对象需要被映射到n个node上,简单hash就求余映射hash(object)%n->node,就大致均匀的分布到n个node上了. 可是问题在于如果n发生变化(多了或者少了),就必须重新计算保存对象存放到node,这代价未免有点大.

PacificA 一致性协议解读

- -
公司数据库的一致性协议用的是 PacificA,相信更多人对 raft 比较了解(毕竟是许多大学钦定的教学算法,不曾了解过的可以看这里. 快速理解一致性协议 raft),这篇文章写给懂 raft 的读者. PacificA 的 paper 在 08 年左右发出来的,比 Raft 早了 6,7 年. 在 PacificA 论文中,他们强调该算法使用范围是.

最终一致性的常用做法

- - 互联网 - ITeye博客
利用数据库的事务特性来满足事务的一致性,这时候的一致性是强一致性的. 针对多数据库事务可以根据二阶段提交协议,采用spring 3.0 + Atomikos + JTA进行支持;. 3、基于事务型消息队列的最终一致性. 借助消息队列,在处理业务逻辑的地方发送消息,业务逻辑处理成功后,提交消息,确保消息是发送成功的,之后消息队列投递来进行处理,如果成功,则结束,如果没有成功,则重试,直到成功,不过仅仅适用业务逻辑中,第一阶段成功,第二阶段必须成功的场景.