免费网站推广的方法,茂名百度搜索网站排名,seo专员工作内容,怎么做网站的项目预算1. 对分布式事务的了解 分布式事务是企业集成中的一个技术难点#xff0c;也是每一个分布式系统架构中都会涉及到的一个东西#xff0c; 特别是在微服务架构中#xff0c;几乎可以说是无法避免。
首先要搞清楚#xff1a;ACID、CAP、BASE理论。
ACID 指数据库事务正确执行…1. 对分布式事务的了解 分布式事务是企业集成中的一个技术难点也是每一个分布式系统架构中都会涉及到的一个东西 特别是在微服务架构中几乎可以说是无法避免。
首先要搞清楚ACID、CAP、BASE理论。
ACID 指数据库事务正确执行的四个基本要素 1.原子性Atomicity 2.一致性Consistency 3.隔离性Isolation 4.持久性Durability
CAP CAP原则又称CAP定理指的是在一个分布式系统中一致性Consistency、可用性Availability、分区容忍性Partition tolerance。 CAP 原则指的是这三个要素最多只能同时实现两点不可能三者兼顾。
一致性 在分布式系统中的所有数据备份在同一时刻是否同样的值。 可用性 在集群中一部分节点故障后集群整体是否还能响应客户端的读写请求。 分区容忍性 以实际效果而言分区相当于对通信的时限要求。系统如果不能在时限内达成数 据一致性就意味着发生了分区的情况必须就当前操作在C和A之间做出选择。
BASE理论 BASE理论是对CAP中的一致性和可用性进行一个权衡的结果理论的核心思想就是我们无法做到强一致但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性。 1.Basically Available基本可用 2.Soft state软状态 3.Eventually consistent最终一致性
2.简单一次完整的 HTTP 请求所经历的步骤 1、 DNS 解析(通过访问的域名找出其 IP 地址递归搜索)。 2、HTTP 请求当输入一个请求时建立一个 Socket 连接发起 TCP的 3 次握手。如果是 HTTPS 请求会略微有不同。。 3.1、客户端向服务器发送请求命令一般是 GET 或 POST 请求。 客户端的网络层不用关心应用层或者传输层的东西主要做的是通过查找路由表确定如何到达服务器期间可能经过多个路由器这些都是由路由器来完成的工作我不作过多的描述无非就是通过查找路由表决定通过那个路径到达服务器。 客户端的链路层包通过链路层发送到路由器通过邻居协议查找给定 IP 地址的 MAC 地址然后发送 ARP 请求查找目的地址如果得到回应后就可以使用 ARP 的请求应答交换的 IP 数据包现在就可以传输了然后发送 IP 数据包到达服务器的地址。 3.2、客户端发送请求头信息和数据。 4.1、服务器发送应答头信息。 4.2、服务器向客户端发送数据。 5、服务器关闭 TCP 连接4次挥手。 这里是否关闭 TCP 连接也根据 HTTP Keep-Alive 机制有关。同时客户端也可以主动发起关闭 TCP 连接。 6、客户端根据返回的 HTML 、 CSS 、 JS 进行渲染。
3.分布式事务解决方案 1.两阶段提交(2PC) 2.三阶段提交(3PC) 3.补偿事务(TCCTry-Confirm-Cancel) 4.本地消息队列表(MQ) 5.Sagas事务模型(最终一致性)
4.什么是二阶段提交 两阶段提交2PC是分布式事务中最强大的事务类型之一两段提交就是分两个阶段提交 第一阶段询问各个事务数据源是否准备好。 第二阶段才真正将数据提交给事务数据源。
为了保证该事务可以满足ACID就要引入一个协调者Cooradinator。其他的节点被称为参与者Participant。协调者负责调度参与者的行为并最终决定这些参与者是否要把事务进行提交。 处理流程如下 阶段一 a) 协调者向所有参与者发送事务内容询问是否可以提交事务并等待答复。 b) 各参与者执行事务操作将 undo 和 redo 信息记入事务日志中但不提交事务。 c) 如参与者执行成功给协调者反馈 yes否则反馈 no。 阶段二 如果协调者收到了参与者的失败消息或者超时直接给每个参与者发送回滚(rollback)消息否则 发送提交(commit)消息。两种情况处理如下 情况1 当所有参与者均反馈 yes提交事务 a) 协调者向所有参与者发出正式提交事务的请求即 commit 请求。 b) 参与者执行 commit 请求并释放整个事务期间占用的资源。 c) 各参与者向协调者反馈 ack(应答)完成的消息。 d) 协调者收到所有参与者反馈的 ack 消息后即完成事务提交。 情况2 当有一个参与者反馈 no回滚事务 a) 协调者向所有参与者发出回滚请求即 rollback 请求。 b) 参与者使用阶段 1 中的 undo 信息执行回滚操作并释放整个事务期间占用的资源。 c) 各参与者向协调者反馈 ack 完成的消息。 d) 协调者收到所有参与者反馈的 ack 消息后即完成事务。
问题 1)性能问题 所有参与者在事务提交阶段处于同步阻塞状态占用系统资源容易导致性能瓶颈。 2)可靠性问题 如果协调者存在单点故障问题或出现故障提供者将一直处于锁定状态。 3)数据一致性问题 在阶段 2 中如果出现协调者和参与者都挂了的情况有可能导致数据不一致。 优点 尽量保证了数据的强一致适合对数据强一致要求很高的关键领域。其实也不能100%保证 强一致。 缺点 实现复杂牺牲了可用性对性能影响较大不适合高并发高性能场景。
5.什么是三阶段提交 三阶段提交是在二阶段提交上的改进版本3PC最关键要解决的就是协调者和参与者同时挂掉的问题所以3PC把2PC的准备阶段再次一分为二这样三阶段提交。 处理流程如下 阶段一 a) 协调者向所有参与者发出包含事务内容的 canCommit 请求询问是否可以提交事务并等待所有参与者答复。 b) 参与者收到 canCommit 请求后如果认为可以执行事务操作则反馈 yes 并进入预备状态否则反馈 no。
阶段二 协调者根据参与者响应情况有以下两种可能。 情况1 所有参与者均反馈 yes协调者预执行事务 a) 协调者向所有参与者发出 preCommit 请求进入准备阶段。 b) 参与者收到 preCommit 请求后执行事务操作将 undo 和 redo 信息记入事务日志中但不提交事务。 c) 各参与者向协调者反馈 ack 响应或 no 响应并等待最终指令。 情况2 只要有一个参与者反馈 no或者等待超时后协调者尚无法收到所有提供者的反馈即中断事务。 a) 协调者向所有参与者发出 abort 请求。 b) 无论收到协调者发出的 abort 请求或者在等待协调者请求过程中出现超时参与者均会中断事务。
阶段三 该阶段进行真正的事务提交也可以分为以下两种情况。 情况 1 所有参与者均反馈 ack 响应执行真正的事务提交。 a) 如果协调者处于工作状态则向所有参与者发出 do Commit 请求。 b) 参与者收到 do Commit 请求后会正式执行事务提交并释放整个事务期间占用的资源。 c) 各参与者向协调者反馈 ack 完成的消息。 d) 协调者收到所有参与者反馈的 ack 消息后即完成事务提交。 情况2 只要有一个参与者反馈 no或者等待超时后协调组尚无法收到所有提供者的反馈即回滚事务。 a) 如果协调者处于工作状态向所有参与者发出 rollback 请求。 b) 参与者使用阶段 1 中的 undo 信息执行回滚操作并释放整个事务期间占用的资源。 c) 各参与者向协调组反馈 ack 完成的消息。 d) 协调组收到所有参与者反馈的 ack 消息后即完成事务回滚。 优点 相比二阶段提交三阶段提交降低了阻塞范围在等待超时后协调者或参与者会中断事务。 避免了协调者单点问题。阶段 3 中协调者出现问题时参与者会继续提交事务。 缺点 数据不一致问题依然存在当在参与者收到 preCommit 请求后等待 do commite 指令时 此时如果协调者请求中断事务而协调者无法与参与者正常通信会导致参与者继续提交事务造成数据不一致。
6.什么是补偿事务 TCC Try Confirm Cancel 是服务化的二阶段编程模型采用的补偿机制 TCC 其实就是采用的补偿机制其核心思想是针对每个操作都要注册一个与其对应的确认和补偿撤销操作。 它分为三个步骤 一、 Try 阶段主要是对业务系统做检测及资源预留。 二、 Confirm 阶段主要是对业务系统做确认提交Try阶段执行成功并开始执行 Confirm阶段时默认 Confirm阶段是不会出错的。即只要Try成功Confirm一定成功。 三、 Cancel 阶段主要是在业务执行错误需要回滚的状态下执行的业务取消预留资源释放。
举个例子假入 你 要向 老王 转账思路大概是 我们有一个本地方法里面依次调用步骤 1、 首先在 Try 阶段要先调用远程接口把 你 和 老王 的钱给冻结起来。 2、 在 Confirm 阶段执行远程调用的转账的操作转账成功进行解冻。 3、 如果第2步执行成功那么转账成功如果第二步执行失败则调用远程冻结接口对应的解冻方法 (Cancel)。 优点 性能提升 具体业务来实现控制资源锁的粒度变小不会锁定整个资源。 数据最终一致性 基于 Confirm 和 Cancel 的幂等性保证事务最终完成确认或者取消保证数据的一致性。 可靠性 解决了 XA 协议的协调者单点故障问题由主业务方发起并控制整个业务活动业务活动管理器也变成多点引入集群。 缺点 TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现业务耦合度较高提高了开发成本。
