专门做旅行用品的网站自己怎么找回智慧团建密码

当前位置： 首页 > news >正文

专门做旅行用品的网站,自己怎么找回智慧团建密码,网页设计规范的主要内容,网站建设越来越难做什么是分布式事务#xff1f; 首先理解什么是本地事务 平时我们在程序中通过Spring去控制事务是利用数据库本身的事务特性来实现的#xff0c;因此叫数据库事务#xff0c;由于应用主要靠关系数据库来控制事务#xff0c;而数据库通常和应用在同一个服务器#xff0c;所…什么是分布式事务 首先理解什么是本地事务 平时我们在程序中通过Spring去控制事务是利用数据库本身的事务特性来实现的因此叫数据库事务由于应用主要靠关系数据库来控制事务而数据库通常和应用在同一个服务器所以基于关系型数据库的事务又被称为本地事务 本地事务具有ACID四大特性 原子性Atomicity事务是一个不可分割的工作单位事务中的操作要么全部成功要么全部失败。一致性Consistency事务在执行前后必须保持数据的一致性即满足业务逻辑和约束条件。隔离性Isolation事务之间不应相互干扰每个事务都应该在独立的环境中执行不受其他事务的影响。持久性Durability事务一旦提交其对数据的修改就应该永久保存在数据库中即使发生系统故障或崩溃也不会丢失。 数据库事务在实现时会将一次事务涉及到的所有操作全部纳入到一个不可分割的执行单元该执行单元中的所有操作要么都成功要么都失败只要其中任一操作执行失败都将导致整个事务的回滚 理解了本地事务那么什么是分布式事务 现在的需求是课程发布操作后将数据写入数据库、Redis、ElasticSearch、MinIO四个地方这四个地方已经不限制在一个数据库内而是由四个分散的服务去提供与这四个服务去通信需要网络通信而网络存在不可到达性例如突然断网在这种分布式系统环境下通过与不同的服务进行网络通信去完成事务称之为分布式事务 在分布式系统中分布式事务的场景有很多例如用户注册送积分、银行转账、创建订单减库存这些都是分布式事务 拿转账举例我们知道本地事务依赖数据库本身提供的事务特性来实现因此以下逻辑可以控制本地事务 begin transaction; // 1. 本地数据库操作张三减少金额 // 2. 本地数据库操作李四增加金额 end transaction;但是在分布式环境下会变成这样 begin transaction; // 1. 本地数据库操作张三减少金额 // 2. 远程调用李四增加金额 end transaction;可以设想当远程调用让李四增加金额成功了由于网络原因导致远程调用的结果没有返回此时本地事务提交失败就回滚了张三减少金额的操作此时张三和李四的数据就不一致了 因此在分布式框架的基础上传统数据库事务就无法使用了张三和李四的账户不在同一个数据库甚至不在同一个应用系统里实现转账事务需要远程调用由于网络问题就会导致分布式事务问题 什么是CAP理论 控制分布式事务首先需要理解CAP理论什么是CAP理论 CAP理论是一个分布式系统设计的重要理论它指出一个分布式系统最多只能同时满足一致性Consistency、可用性Availability和分区容忍性Partition tolerance这三项中的两项。 一致性是指所有节点访问同一份最新的数据副本可用性是指每个请求都能得到响应分区容忍性是指系统能够在网络分区的情况下继续运行。 举例一个网关两个节点 客户端经过网关访问用户服务的两个节点 一致性是指用户不管访问哪一个节点拿到的数据都是最新的相同的例如查询小明的信息不能出现在数据没有改变的情况下两次查询结果不一样 可用性是指任何时候查询用户信息都可以查询到结果但是不保证查询到的是最新的数据 分区容忍性也叫分区容错性由于网络通信异常导致请求终端、消息丢失单服务依然对外提供服务 CAP理论要强调的是在分布式系统中这三点不可能全部满足因为只要是分布式系统就要满足分区容忍性因为服务间难免会出现网络异常不能因为局部网络异常就导致整个系统不可用 满足分区容忍性的条件下一致性和可用性不能同时满足 例如我们添加一个用户小明的信息该信息先添加到结点1中再同步到结点2中 如果满足C一致性必须等待小明的信息同步完成后系统才可用否则当你查询结点2的时候会查不到数据违背了一致性 如果满足A可用性要时刻保证系统可用就不用等待信息同步完成此时系统的一致性就无法满足 所以C和A不能同时满足在分布式系统中进行分布式事务控制要么保证CP、要么保证AP 分布式事务控制方案 学习CAP理论我们知道进行分布式事务控制要在C一致性和A可用性中做出取舍保证一致性就不要保证可用性保证可用性就不要保证一致性。 首先要确认我们的需求是要CP还是AP具体要根据应用场景进行判断 CP的场景满足C舍弃A强调一致性 跨行转账一次转账请求要等待双方银行系统都完成整个事务才算完成只要其中一个失败另一方执行回滚操作 开户操作在业务系统开户同时要在运营商开户任何一方开户失败该用户都不可使用新开账户要满足一致性 AP的场景满足A舍弃C强调可用性 订单退款今日退款成功明日账户到账只要用户可以接受在一定时间内到账即可 注册送积分注册成功积分在24小时内到账 支付短信通信支付成功发短信短信发送可以有延迟 在实际应用中符合AP的场景比较多虽然AP舍弃C的一致性但实际最终数据还是保持了一致所以业界定义了BASE理论 BASE 理论 BASE是Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。 基本可用当系统无法满足全部可用时保证核心业务可用即可比如一个外卖系统到了饭点的时候系统并发量很高此时要保证下单流程涉及的服务可用其他服务暂不可用 软状态可以存在中间状态例如微博的评论功能。当用户发表一条评论时这条评论并不会立即同步到所有关注者的页面上而是会先存储在缓存中并逐渐传播到其他节点。这样就存在了一个中间状态即某些用户可以看到这条评论而某些用户还不能看到。 最终一致性前面的软状态并不影响微博的整体可用性用户仍然可以正常浏览和发表微博。最终在一定时间内所有关注者都能看到这条评论达到了最终一致性。 分布式事务常见的技术方案 实现CP就需要强一致性 例如Seata AT模式、TCC模式 实现AP保证最终一致性 消息队列通知失败自动重试超过最大次数手动处理、任务调度 在我们的系统中课程发布操作后将数据写入数据库、Redis、ElasticSearch、MinIO采用定时任务利用将发布课程消息表来记录任务任务完成删除消息表记录任务没完成则下一轮定时任务会重新执行。