怎么用dw第一次做网站天津做填料的公司

怎么用dw第一次做网站,天津做填料的公司,做网站如何调字体格式,建设银行网站钓鱼引言随着互联网业务向高并发、高可用、大规模数据演进#xff0c;传统单体架构中的本地事务#xff08;Local Transaction#xff09;越来越无法满足需求。数据库需要拆分、服务需要拆分#xff0c;随之而来的就是对 分布式事务#xff08;Distributed Transaction#x…引言随着互联网业务向高并发、高可用、大规模数据演进传统单体架构中的本地事务Local Transaction越来越无法满足需求。数据库需要拆分、服务需要拆分随之而来的就是对分布式事务Distributed Transaction的需求。然而分布式事务不仅复杂而且涉及大量理论体系因此常是中高级工程师绕不开的知识点。本文将从背景、理论体系、事务模型到 2PC/3PC 协议一次讲透分布式事务的全貌。一、分布式事务产生的背景分布式事务并不是无中生有而是由业务规模和系统架构演进推动的 —— 你无法避免也无法绕过。1. 数据库水平拆分Sharding当单库数据量太大、连接数无法承受、IO发生瓶颈时我们必须做垂直拆分按业务拆表水平拆分按用户ID、订单ID分片拆分之后一个业务操作可能需要跨多个数据库完成。例如订单库order-db保存订单信息 库存库stock-db保存库存信息 支付库payment-db保存支付流水创建订单可能需要创建订单order-db扣减库存stock-db记录扣费流水payment-db跨库意味着事务不能再依赖单库的 ACID本质上触发了分布式事务需求。2. 业务服务化拆分微服务化在微服务架构中一个完整流程由多个服务协同完成例如OrderService → StockService → PaymentService每个服务背后有自己的数据库、缓存、消息队列…服务之间通过网络调用本质是分布式系统。这意味着一个业务逻辑跨多个服务因为每个服务有独立数据库所以必然跨库服务调用失败的概率远高于本地方法调用需要通过分布式事务保障一致性所以数据库的拆分 服务的拆分 分布式事务不可避免二、分布式事务的理论基础分布式事务必须建立在三个基础理论上CAP 定理BASE 理论ACID 扩展不过本文不展开 CAP/BASE而直接进入事务的分类和模型。三、分布式事务类型刚性事务与柔性事务分布式事务大体分两类刚性事务Rigid和柔性事务Flexible。1. 刚性事务Rigid Transaction—— 强一致性特点保证 ACID事务在分布式环境仍保持严格一致性通常依赖XA、2PC、3PC协议实现代表XA两阶段提交分布式数据库内部事务如 OceanBase、TiDB 等优势强一致性应用端简单缺点高延迟长时间锁资源规模扩展受限适用场景银行式核心金融交易、金额绝对不能错的场景。2. 柔性事务Flexible Transaction—— 最终一致性柔性事务追求最终一致性不会追求某一时刻必须一致。柔性事务又分1补偿型事务Saga、TCC有明确的正向操作补偿操作各阶段失败后通过补偿回滚适用于业务可以“人工撤销”可实现业务补偿逻辑典型例子机票 酒店 租车的旅行预订。2通知型事务可靠事件型基于消息队列生产者先落本地表再投递消息消费者最终处理成功即可适用于对一致性要求不是绝对强如积分系统、异步通知、营销系统四、为什么需要补偿型分布式事务因为分布式系统中有三个无法避免的问题网络是不可靠的延迟、丢包服务会挂、节点会崩资源跨库和跨服务不可能锁住太久传统的强一致例如 2PC有一个致命缺点阻塞所有参与者必须等待协调者指令网络抖动可能导致事务长时间锁表/锁资源在现代高并发业务中这种方式不可接受。因此补偿型事务Saga、TCC成为主流允许失败时通过业务逻辑修复补偿避免长时间锁资源五、分布式事务模式AT / TCC / Saga / XA详解1. XA2PC模型—— 强一致性优点标准化框架支持简单缺点性能差强依赖协调器容易阻塞2. TCCTry–Confirm–Cancel关键思想Try 预留资源 Confirm 真正提交 Cancel 释放资源优点强控制力业务可控缺点需要大量补偿业务代码成本高、开发复杂3. Saga —— 长事务补偿模型Saga 一系列可独立提交的本地事务 逆向补偿操作。结构T1, T2, T3 ... C1, C2, C3 ...补偿优点最易落地不锁资源缺点不能解决强一致性补偿逻辑较复杂4. AT 模式SeataAT 自动回滚/提交不需要业务侧写 TCC 代码。原理通过 UndoLog 记录数据快照通过二阶段自动提交或回滚提供最终一致性适合中间态兼顾性能和易用性。六、分布式事务协议2PC 与 3PC下面进入核心 ——分布式事务协议。1. 两阶段提交2PC2PCTwo Phase Commit分两阶段阶段 1准备阶段Prepare协调者向所有参与者发送是否可以提交prepare参与者执行本地事务写入 redo log锁定资源返回投票YES 或 NO阶段 2提交阶段Commit/Rollback如果所有参与者返回 YES协调者广播 COMMIT参与者提交本地事务、释放锁若任意一个返回 NO 或超时协调者广播 ROLLBACK2PC 的优点实现简单实际使用最广泛强一致性保证2PC 的缺点致命同步阻塞所有参与者被锁住协调者单点故障无法解决网络分区导致的“悬挂问题”例如参与者已提交但协调者以为失败并要求回滚2PC 的这些缺陷催生了 3PC。2. 三阶段提交3PC3PCThree Phase Commit引入超时机制增加一个准备确认阶段三个阶段1. CanCommit询问阶段协调者仅询问是否能提交不执行事务。2. PreCommit预提交阶段参与者执行操作但不提交进入预提交状态。3. DoCommit提交阶段协调者最终下达指令超时仍无响应默认提交安全更好3PC 的优点引入超时机制减少阻塞降低协调者阻塞造成的风险3PC 的缺点实现复杂即使加入超时依然无法完全避免网络分区导致数据不一致工业界采用相对较少更多见于理论与特定分布式数据库总结内容说明产生背景数据库拆分、服务拆分事务类型刚性ACID vs 柔性最终一致模式XA、TCC、Saga、AT协议2PC、3PC为什么要补偿避免长锁、应对失败场景实际落地多用柔性事务TCC/Saga/AT