《大规模soa系统中的分布事务处事_程立》由会员分享，可在线阅读，更多相关《大规模soa系统中的分布事务处事_程立（35页珍藏版）》请在金锄头文库上搜索。
1、大规模SOA系统中的分布事务处理程立 支付宝产品技术与用户体验部 2008年12月提要 从单应用系统的事务 到大规模SOA系统中 的事务 内容提要 山穷水尽(背景与历史) 柳暗花明(原则与模式) 又一山寨(框架与设施)应用数据库数据遗留系统集成开放服务流程服务客户的系统业务服务领域服务合作伙伴的系统合作伙伴集成门户服务数据数据数据数据数据10:332山穷水尽Googling “transaction processing” 约有1,940,000项符合的查询结果 “distributed transaction” 约有260,000项符合的查询结果 “distributed transacti
2、on”+ practice 约有24,700项符合的查询结果 “distributed transaction”+ “success story” 约有265项符合的查询结果 ? “distributed transaction” + sucks 约有1,370项符合的结果 “distributed transaction” + hope 约有17,500项符合的结果 10:333事务事务: 由一组操作构成的可靠、 独立的工作单元 ACID: Atomicity(原子性) Consistency(一致性) Isolation(隔离性) Durability(持久性) 难点: 高度并发 资源分布
3、 大时间跨度操作时间资源位置A112345ABCC1B3C4A5事务1事务2事务310:334本地事务本地事务 事务由资源管理器（如 DBMS）本地管理 优点 支持严格的ACID属性 可靠 高效 状态可以只在资源管理器 中维护 应用编程模型简单(在框 架或平台的支持) 局限 不具备分布事务处理能力 隔离的最小单位由资源管 理器决定，如数据库中的 一条记录应用/应用服务器/应用框架 AP资源管理器 RM开始会话开始事务操作1操作n提交/回滚事务完成会话锁日志10:335资源 管理器 RM2全局事务(DTP模型)应用/应用框架/应用服务器 AP资源 管理器 RM13. 操作1n6. 提交事务事务
4、管理器 TM1. 开始全局事务2. 注册资源14. 注册资源25. 操作1n7. 准备8. 准备9. 提交10. 提交全局事务 事务由全局事务管理 器全局管理 事务管理器 管理全局事务状态与 参与的资源，协同资 源的一致提交/回滚 TX协议 应用或应用服务器与 事务管理器的接口 XA协议 全局事务管理器与资 源管理器的接口10:336两阶段提交(Two Phase Commit)准备操作与ACID A: 准备后，仍可提交与回滚 C: 准备时，一致性检查必须 OK I: 准备后，事务结果仍然只 在事务内可见 D: 准备后，事务结果已经持 久 局限 协议成本 (准备操作是一定 必须的吗） 准备阶段
5、的持久成本 全局事务状态的持久成本 潜在故障点多带来的脆弱性 准备后，提交前的故障引发 一系列隔离与恢复难题事务管理器 TM资源管理器 RM11. 准备OK3. 提交OK资源管理器 RM22. 准备OK4. 提交OK事务管理器 TM资源管理器 RM11. 准备OK3. 回滚OK资源管理器 RM22. 准备NO4. 回滚OK10:337通信资源 管理器 CRM通信资源 管理器 CRM跨域的全局事务(DTP模型)问题 事务上下文如何跨域传递? 多事务管理器如何协同? 异构事务域间的标准是什么? 通信资源管理器 管理事务域间或事务域内的 通信，允许全局事务信息跨 域传递 XA+协议 是XA的超集，增
6、加指令使事 务管理器间可以相互协同 局限 更高协议成本 脆弱，故障点多 故障影响大，恢复困难 复杂，更多架构与平台约束应用/应用框架/应用服务器 AP资源 管理器 RM1事务 管理器 TM资源 管理器 RM通信资源 管理器 CRM应用/应用框架/应用服务器 AP资源 管理器 RM1事务 管理器 TM资源 管理器 RM通信资源 管理器 CRM主事务域分支事务域XATXXATXXA+XA+TxRPC等TxRPC等10:338Java企业平台中的分布事务实现JTA 面向应用、应用服务器与资源 管理器的高层事务接口 JTS JTA事务管理器的实现标准，向 上支持JTA，向下通过CORBA OTS实现跨
7、事务域的互操作性 EJB 基于组件的应用编程模型，通 过声明式事务管理进一步简化 事务应用的编程 优点 简单一致的编程模型 跨域分布处理的ACID保证 局限 DTP模型本身的局限 缺少充分公开的大规模、高可 用、密集事务应用的成功案例 10:339其它资源WS-Transaction标准 OASIS组织通过的Web Service 事务标准，包含WS- Cordination、WS- AtomicTransaction、WS- BusinessActivity JbossTransactions系统 开源的JTA、JTS、WS- Transaction标准的实现 Paxos算法 分布式系统中就
8、某个提议达成 一致决议的算法族10:3310柳暗花明原则 真正重要的是满足业务需求， 而不是追求抽象、绝对的系统 特性 帽子戏法：两只手最多能拿几 顶帽子？ 酸碱平衡(ACID-BASE Balance) 模式 服务模式 1. 可查询操作 2. 幂等操作 3. TCC操作 4. 可补偿操作 复合模式 1. 定期校对 2. 可靠消息 3. TCC 4. 补偿10:3311帽子戏法CAP定理对于共享数据系统，只能同时拥有 以下三项中的两个： Consistency(一致性): 所有 用户看到一致的数据 Availability(可用性): 总能找 到一个可用的数据复本 Tolerance to N
9、etwork Partition(分区容忍性): 即使 在系统被分区的情况下，仍 然满足上述两点10:3312酸碱平衡BASEBA(Basic Availability) 基本可用性 S(Soft state) 柔性状态 E(Eventuall consistency) 最终一致性10:3313eBay的BASE最佳实践At eBay, we allow absolutely no clientside or distributed transactions of any. Of course, we do employ various techniques to help the syste
10、m reach eventual consistency: careful ordering of database operations, asynchronous recovery events, and reconciliation or settlement batches. We choose the technique according to the consistency demands of the particular use case.Randy Shoup，eBay的杰出架构师10:3314服务模式1: 可查询操作服务操作的可标识性 服务操作具有全局唯一标识 可以使用业
11、务单据号 或者使用系统分配的操作流水号 或者使用操作资源的唯一标识+ 操作类型的组合 操作有唯一的、确定的时间(约定 以谁的时间为准)单笔查询 使用全局唯一的服务操作标识， 查询操作执行结果 小心“处理中”状态批量查询 使用时间区段与(或)一组服务操 作的标识，查询一批操作执行结 果业务服务doXqueryXbatchQueryX10:3315复合模式1: 定期校对实现 业务活动的主动方，在完成业务处理 之后，向业务活动的被动方发送消息 。允许消息丢失。 业务活动的被动方根据定时策略，向 业务活动主动方查询，恢复丢失的业 务消息。 约束 被动方的处理结果不影响主动方的处 理结果 成本 业务查询
12、与校对系统的建设成本 适用范围 对业务最终一致性的时间敏感度低 跨企业的业务活动业务处理服务实时消息服务数据库实时处理网关数据库定期校对系统事务域事务域业务处理服务业务查询/下载服务主动方被动方10:3316保证消息在事务提交后才发送要求 消息发送必须严格在事务提交后 方可进行一种实现方案 使用拦截器拦截发送消息请求 拦截器检测到当前存在活动事务 ，就创建一个事务同步器 并向事务管理器注册事务同步器 业务处理事务完成后，事务管理 器会调用事务同步器 事务同步器判断当前事务状态为 已提交，才真正发送消息业务处理服务消息服务事务同步器事务管理器拦截器1. 开始事务4. 提交事务数据库2. 操作3.
13、 发消息3.1 创建事务同步器3.2 注册事务同步器4.1 调用事务同步器4.1.1 发消息10:3317服务模式2: 幂等操作幂等性(Idempotenty) f(f(x) = f(x)幂等操作 重复调用多次产生的业务结果与 调用一次产生的业务结果相同实现方式一 通过业务操作本身实现幂等性实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后，自动返回 之前的处理结果业务服务doX10:3318复合模式2: 可靠消息实现 业务活动的主动方，在完成业务处理的 同一个本地事务中，记录消息数据 业务处理事务提交后、通过实时消息服 务通知业务被动方，实时通知成功后删 除消息数据 消息恢复系统定期
14、找到未成功发送的消 息，交给实时消息服务补发送 约束 被动方的处理结果不影响主动方的处理 结果 被动方的消息处理操作是幂等操作 成本 可靠消息系统建设成本 消息数据CRUD成本 适用范围 对最终一致性时间敏感度较高 降低业务被动方实现成本业务处理服务实时消息服务实时处理网关数据库事务域事务域业务处理服务主动方被动方业务数据消息数据消息恢复系统10:3319可靠消息的另一种实现实现 业务处理服务在业务事务提交前，向实 时消息服务请求发送消息，实时消息服 务只记录消息数据，而不真正发送 业务处理服务在业务事务提交后，向实 时消息服务确认发送。只有在得到确认 发送指令后，实时消息服务才真正发送 消息
15、 业务处理服务在业务事务回滚后，向实 时消息服务取消发送 消息状态确认系统定期找到未确认发送 或回滚发送的消息，向业务处理服务询 问消息状态，业务处理服务根据消息ID 或消息内容确定该消息是否有效 成本 一次消息发送需要两次请求 业务处理服务需实现消息状态回查接口 优点 消息数据独立存储、独立伸缩 降低业务系统与消息系统间的耦合业务处理服务实时消息服务事务域业务数据消息恢复系统消息数据消息状态确认系统事务域发送消息请求发送确认发送取消发送询问消息状态10:3320服务模式3: TCC操作Try: 尝试执行业务 完成所有业务检查(一致性) 预留必须业务资源(准隔离性) Confirm:确认执行业
16、务 真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作满足幂等性 Cancel: 取消执行业务 释放Try阶段预留的业务资源 Cancel操作满足幂等性 与2PC协议比较 位于业务服务层而非资源层 没有单独的准备(Prepare)阶段，Try操作 兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定粒度 较高开发成本业务服务tryXconfirmXcancelX10:3321复合模式3: TCC模式实现 一个完整的业务活动由一个主业务服务与若 干从业务服务组成 主业务服务负责发起并完成整个业务活动 从业务服务提供TCC型业务操作 业务活动管理器控制业务活动的一致性，它 登记业务活动中的操作，并在业务活动提交 时确认所有的TCC型操作的confirm操作，在
