企业为什么要建设自己的网站,谷歌网站地图在线生成,重庆市建设工程信息网查证件,让人做网站需要准备什么软件亲爱的,关注我吧为了保证分布式环境下数据强一致性#xff0c;需要引入分布式事务#xff0c;而分布式事务由于网络环境的不确定性#xff0c;天生就很难实现。具体可以见上一篇。[分布式下#xff0c;我想要强一致性]为了保证分布式事务的正确性#xff0c;目前互联网领域… 亲爱的,关注我吧为了保证分布式环境下数据强一致性需要引入分布式事务而分布式事务由于网络环境的不确定性天生就很难实现。具体可以见上一篇。[分布式下我想要强一致性]为了保证分布式事务的正确性目前互联网领域有几种流行的解决方案但是大部分都没有像XA事务一样形成标准的工业规范。但是这些方案在某些特定的行业或者业务场景下却得到了越来越多的开发者的认可。避免分布式事务此方案提倡尽量避免分布式事务不仅仅是因为分布式事务的难度更是因为实现分布式事务需要更多的高级人才。如果一个操作设计到事务操作而这些事务操作可以利用单机事务来解决推荐首选单机事务。当然是否可以避免分布式事务还要看具体业务在微服务盛行的当下更多的还要看领域的划分标准如果两个微服务可以合并成一个微服务一定程度上在领域划分标准接受范围之内可以考虑利用合并的方式来避免分布式服务。举一个很简单的栗子一个用户基本信息服务和用户资产服务比如用户经验值当用户修改资料的时候给用户加贡献值这个业务场景下因为涉及到用户资料修改和加贡献值两个不同服务的操作这个时候就可以考虑将两个服务合并为一个服务用单机的数据库事务来代替分布式事务。在可以避免分布式事务的情况下首选避免分布式事务二阶段提交二阶段2PC提交方案是基于X/OpenDTP标准规范的最大的缺点在于它在第一阶段需要锁定资源会大大降低系统的性能大型的互联网应用并不推荐这种方案那种对性能不敏感的企业级应用可以尝试使用。在asp.net中微软已经提供了分布式事务的管理类型TransactionScope它依赖DTCDistributed Transaction Coordinator服务完成事务一致性。当它包裹的代码中如果设计到多个不同物理位置的数据库的时候它会自动升级为分布式事务使用起来非常方便。using (TransactionScope ts new TransactionScope()){数据库A操作();数据库B操作();数据库C操作();ts.Complete();}TCCTCC本质上是一种编程模型它提倡的是补偿操作所以一般情况下它会有重试机制它约定参与事务的每个业务方都需要提供三个接口具体情况请查看上一篇文章。由于TCC的接口重试特性所以提供的提交和取消接口必须实现幂等性。2PC主要是针对数据库操作而TCC主要是针对业务层面来进行操作这在性能上比2PC要高很多例如一个提交订单的场景商品服务需要扣除库存而订单系统需要创建订单代码类似以下请不要纠结命名和参数using (TransactionScope ts new TransactionScope()){数据库A操作();//订单服务
public interface IOrderService
{//创建一个不可见的订单返回订单号Taskstring CreateOrder();//根据订单号提交订单使订单可见Taskint SubmitOrder(string orderNo);//根据订单号取消订单Taskint CancleOrder(string orderNo);
}
//商品服务
public interface IProductService
{//根据商品id锁定库存,返回锁定的idTaskint LockProductStock(int productId);//根据锁定的库存id提交事务扣除商品库存Taskint SubmitLockStock(int lockId);//根据锁定的库存id取消事务商品库存回滚Taskint CancleLockStock(int lockId);
}//订单服务
public interface IOrderService
{//创建一个不可见的订单返回订单号Taskstring CreateOrder();//根据订单号提交订单使订单可见Taskint SubmitOrder(string orderNo);//根据订单号取消订单Taskint CancleOrder(string orderNo);
}
//商品服务
public interface IProductService
{//根据商品id锁定库存,返回锁定的idTaskint LockProductStock(int productId);//根据锁定的库存id提交事务扣除商品库存Taskint SubmitLockStock(int lockId);//根据锁定的库存id取消事务商品库存回滚Taskint CancleLockStock(int lockId);
} 数据库B操作();数据库C操作();ts.Complete();}其实TCC实现过程中还有很多细节。比如当提交事务阶段有一个节点由于网络原因或者down机提交失败该怎么办呢这个时候我们要在本地引入本地消息机制或者叫做业务活动管理器把每个业务参与分布式事务的每个操作都记录下来当某个过程的某个节点操作失败无论是自动发起重试还是手动重试都可以达到最终数据的一致性。基于消息的事务基于消息的分布式事务实现的是最终一致性它是基于BASE理论的一个解决方案最早由eBay提出并实施它采用了消息队列来辅助实现事务控制流程核心思想是将需要分布式处理的任务通过MQ分发给每个业务去异步执行如果任务失败则可以发起系统自动重试或者人工重试的纠正流程。还是以上边的创建订单和扣减库存为栗子1. 首先调用订单服务的创建订单接口创建订单如果创建成功则发送需要扣减库存的消息也可以看做创建订单成功的消息到MQ。2. 商品服务监听扣减库存消息队列如果收到扣减库存消息则执行扣减库存操作如果操作成功则回复MQ删除该消息。如果没有操作成功则准备接收同样消息的下次投递。这个流程看似很完美其实有很多漏洞。- 创建订单是第一步操作可以看做是单纯的单机操作这个并没有问题但是接着发送MQ消息这一步需要和创建订单保证事务性因为会发生创建订单成功发送mq消息失败的情况。如果不能用技术手段来保证这两步的事务也可以采用引入本地消息的方案在创建订单的时候用订单数据库来保证订单创建成功和创建订单消息表的一致性。然后发送mq成功之后修改订单消息表的状态为发送成功如果发送mq消息失败则启用另外一个线程或者进程进行重试。- 商品服务扣减库存类似扣减库存这个操作和回复mq消息这两个操作也可以利用本地消息表的方式来解决一致性问题。当收到扣减库存消息的时候扣减库存和添加消息成功处理记录可以利用数据库的事务来保证一致性如果回复消息队列ack失败就算是有重复消息也可以根据本地的消费消息表来过滤重复消息基于消息的分布式解决方案还有一个劣势如果一个事务的业务参与方非常多消息的发送可能会非常复杂需要非常谨慎的设计。比如以上订单的栗子现在引入了优惠券服务在订单创建成功需要同时扣减库存和优惠券如果优惠券扣减失败需要同时回滚库存和取消订单这也只是三个业务参与方如果是四个五个呢当然这在业务中也许并不常见。基于消息的分布式事务解决方案由于引入了重试机制也需要接口在实现的时候支持幂等性。但从开发的角度这种方案要比tcc以及2pc都要有优势把每个系统之间的耦合度降到了最低而且每个业务方的实现技术可以非常灵活无论是采用java还是c#活着是golang都无所谓。当然市面上基于消息的分布式解决方案各式各样但总体来说都属于最终一致性方案。如果引入消息通道MQ的不稳定性那还需要在各个业务方引入查询机制来确保消息的ack机制。举个栗子如果商品服务已经正常扣减库存由于mq问题始终不能正常ack。这个时候订单服务是否会主动查询商品服务是否已经正常扣库存这个时候整个架构可能就非现在这个样子了这个要是扯起来又是一篇文章了
