分布式事务最终一致性的简单案例 分布式是如何实现的？
分布式是如何实现的？
实现分布式锁的三种
1.基于数据库实现分布式锁；
2.实现基于缓存的分布式锁(Redis等。);
3.基于Zookeeper实现分布式锁：基于数据库的分布式锁的实现
1.悲观锁定使用select … where …进行更新。exclusive locks注意到，:的其他附加功能与第一个功能的实现基本一致。这里需要注意的是 "其中名称锁定 "，并且必须对名称字段进行索引，否则该表将被锁定。在某些情况下，比如表不大，mysql优化器不会取这个索引，会导致锁表的问题。
2.乐观锁和所谓的乐观锁和前面的是基于CAS思想，并不互斥，也不会造成锁等待和消耗资源。在操作过程中，认为没有并发，只有upd。
分布式计算是如何控制事务的？
分布式事务:指涉及操作多个数据库的事务。事实上，同一个库中的事务的概念被扩展到多个库中的事务。目的是确保分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以随时随地知道事务的所有动作，事务提交或回滚的决策必须产生统一的结果(全部提交或全部回滚)。
X/Open组织(现在的Open Group)定义了分布式事务处理模型。X/Open DTP model (1994)包括应用程序(AP)、事务管理器(TM)、资源管理器(RM)和通信资源管理器(CRM)四个部分。通常，公共事务管理器(TM)是事务中间件，公共资源管理器(RM)是数据库，公共通信资源管理器(CRM)是消息中间件。XA是X/Open DTP定义的交易中间件与数据库之间的接口规范(即接口函数)，交易中间件用它来通知数据库交易的开始和结束，以及提交和回滚。XA接口函数由数据库厂商提供。二阶提交协议和三阶提交协议都是从这个思路衍生出来的。可以说，两阶段提交实际上是实现XA分布式事务的关键(确切地说，两阶段提交主要是保证分布式事务的原子性，即所有节点要么做，要么根本不做)。
因此，大多数关系数据库通过两阶段提交2pc算法完成分布式事务也就不足为奇了。
1.两阶段/三阶段提交
2PC/3PC的全称是: two/three phase commit，中文名是two-phase/three phase submission；为了使所有基于分布式系统架构的节点进步一个在线路事务处理过程中可以用ACID特性设计的算法，需要引入一个组件作为协调器，统一控制所有节点(称为参与者)的操作结果，并最终分两个阶段指示这些节点是否应该真正提交操作结果。算法如下:
第一阶段:提交阶段(投票阶段)
第二阶段:执行交易提交(执行阶段)
这种有很多缺点，在复杂场景下通常不推荐使用，除非是非常简单的场景，非常容易提供回滚，依赖的服务非常少。
2.本地方法表
这种实现的想法其实来自于ebay。其基本设计思想是将远程分布式事务分解成一系列本地事务。如果不考虑性能和优雅的设计，可以借助关系数据库中的表来实现。举一个跨行转账的经典例子来描述一下。
第一步伪代码如下:扣除1W，保证凭证消息通过本地事务插入消息表。
第二步，通知对方银行账户已经加了1W。如何通知对方:可以通过轮询，也可以通过MQ。
方法
伪代码如下，以跨行转账为例。
尝试{1。在本地更新数据库。如果更新成功，执行第二部分。2.通过MQ }catch{rollback()}发送消息如果第一步失败，消息将不会发送到MQ。如果第一步成功，第二步失败，则捕获异常回滚数据，保证数据一致性。
4.交易MQ
有些MQ直接支持分布式交易，比如阿里 s RocketMQ；RocketMQ处理事务消息的一般过程如下:
1.生产者发送待确认的信息；
保存收到的消息，成功后将状态返回给生产者；
3.如果生产者收到的返回是SEND_OK状态，则执行本地事务操作；
4.根据本地事务执行的结果，生产者是执行提交还是回滚；；
5.如果生产者未能执行第四步中的操作，服务器将在一段固定时间后对处于待确认状态的消息发起回溯请求；
6.生产者收到回溯请求后，返回commit或rollback根据本地事务的结果，对本地事务进行处理；
7.服务器收到结果后执行相关操作。
摘要
可以看出，第一种是保证绝对的一致性，这种在互联网行业很少使用，主要是性能不好；最后四种情况都保证 "最终一致性 "，应用广泛；另外，分布式事务其实是一个数据一致性问题，可以关注CAP理论和Base理论；可以多关注我的相关文章。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
