zoukankan      html  css  js  c++  java

  • 分布式事务

    基本概念

    本地事务

    事务由资源管理器（如DBMS）本地管理

    • 优点：严格的ACID
    • 缺点：不具备分布事务处理能力

    全局事务（DTP模型）

    TX协议：应用或应用服务器与事务管理器的接口

    XA协议：全局事务管理器与资源管理器的接口

    • 优点：严格的ACID
    • 缺点：效率非常低

    两阶段提交

    • 优点
      • 准备后，仍可提交或回滚
      • 准备时，一致性检查必须OK
      • 准备后，事务结果仍然只在事务内可见
      • 准备后，事务结果已经持久化
    • 缺点：
      • 潜在故障点多带来的脆弱性
      • 准备后，提交前的故障引发一系列隔离与恢复难题

    http://book.51cto.com/art/201309/410608.htm

    跨域的全局事务（DTP模型）

    • 缺点
      • 更高的协议成本
      • 脆弱，故障点多
      • 故障影响大，恢复困难
      • 复杂，更多架构与平台约束

    java企业平台中的分布式事务实现

    • JTA
      • 面向应用、应用服务器与资源管理器的高层事务接口
    • JTS
      • JTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性
    • EJB
    • 优点
      • 简单一致的编程模型
      • 跨域分布处理的ACID保证
    • 局限
      • DTP模型本身的局限
      • 缺少充分公开的大规模、高可用、密集事务应用的成功案例

    JMS与分布式事务：http://techv5.com/topic/1371/

    其它资源

    • ws-transaction标准
    • jbossTransaction系统
    • Paxos算法

    原则

    • 真正重要的是满足业务需求，而不是追求抽象、绝对的系统特性
    • 帽子戏法
    • 酸碱（ACID-BASE Balance）

    模式

    • 服务模式
      • 可查询操作
      • 幂等操作
      • TCC操作
      • 可补偿操作
    • 复合模式
      • 定期校对
      • 可靠消息
      • TCC
      • 补偿

    CAP定理

    http://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

    对于共享数据系统，只能同时拥有以下三项中的两个：

    • Consistency(一致性): 所有 用户看到一致的数据
    • Availability(可用性): 对数据更新具备高可用性
    • Tolerance to Network Partition(分区容忍性): 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

    理解

    • 允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。
      • 如果是多个节点，然后多个节点都是高可用的，此时肯定有个先后顺序，这时肯定没法保证一致性。
    • 如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。
      • 比如mysql主备节点，一般是主机统一对事务进行控制；备机只用来读。这样就尚失了A性质。
    • 除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
      • 如果要求同时达到一致性和可用性，那就没法分区了，因为一旦分区肯定会有时间窗口导致上面C或A的不满足。

    酸碱平衡 （BASE）

    • BA(Basic Availability)
      • 基本可用性
    • S（soft state）
      • 柔性状态
    • E(Eventuall consistency)
      • 最终一致性

    eBay的BASE最佳实践

    ebay没有使用任何的分布式事务客户端或系统

    他们使用其它技术来保证最终一致性 - careful ordering of database operations - asynchronous recovery events - reconciliation or settlement batches

    分布式事务方案一：定期校对

    服务模式1：可查询操作

    服务操作的可标识性

    服务操作具有全局唯一标识

    复合模式1：定期校对

    http://ww1.sinaimg.cn/bmiddle/60c9620fgw1erk3yotmqkj20f50bzgok.jpg

    需保证在事务提交后才能发送

    分布式事务方案二：基于MQ

    服务模式2：幂等操作

    通过业务操作本身实现幂等性

    服务模式2：可靠消息

    实现：

    • 业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据
    • 业务处理事务提交后、通过实时消息通知业务被动方，实时通知成功后删除消息数据
    • 消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送

    约束：

    • 被动方的处理结果不影响主动方的处理
    • 被动方的消息处理操作是幂等操作

    成本：

    • 可靠消息系统建设成本
    • 消息数据CRUD成本

    适用范围

    • 对最终一致性时间敏感度较高
    • 降低业务被方实现成本

    可靠消息的另一种实现

    实现

    • 业务处理在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送
    • 业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息
    • 业务处理在业务事务回滚后，向实时消息服务取消发送
    • 消息状态确认系统定期找到未确认发送或回溯的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。

    成本

    • 一次消息发送需要两次请求
    • 业务处理服务需实现消息状态回查接口

    优点：

    • 消息数据独立存储、独立伸缩
    • 降低业务系统与消息系统间的耦合

    分布式事务方案三：基于TCC

    服务模式3：TCC操作

    Try: 尝试执行业务

    • 完成所有业务检查（一致性）
    • 预留必须业务资源（准隔离性）

    Confirm: 确认执行业务

    • 真正执行业务
    • 不作任何业务检查
    • 只使用Try阶段预留的业务资源
    • Confirm操作满足幂等性

    Cancel: 取消执行业务

    • 释放Try阶段预留的业务资源
    • Cancel操作满足幂等生

    与2PC协议比较

    • 位于业务服务层而非资源层
    • 没有单独的准备阶段，Try操作兼备资源操作与准备能力
    • Try操作可以灵活选择业务资源的锁定粒度
    • 较高开发成本

    复合模式3：TCC模式

    适用范围 - 强隔离性、严格一致性要求的业务活动 - 适用于执行时间较短的业务

    分布式事务方案四：基于补偿（百度钱包方案）

    适用范围 - 弱隔离性、弱一致性要求的业务活动 - 特别适用于执行时间较长的业务,如工作流

    一般适合于金融系统，例如加钱减钱

    基础设施

    • 服务框架
      • 业务系统jar包
    • 消息系统
      • mq
    • 数据存储
      • 业务活动日志管理
    • 分布式任务调度
      • 业务活动恢复任务
      • 消息恢复任务
      • 定期校对任务
    • 服务注册中心
      • 提供服务元数据集中注册、查询与管理能力，支持事务相关属性的描述

    参考
  • 相关阅读:
    第02组 Beta冲刺（1/4）
    第02组 Alpha事后诸葛亮
    第02组 Alpha冲刺（4/4）
    第02组 Alpha冲刺（3/4）
    团队作业6——复审与事后分析（集合贴）
    事后诸葛亮分析报告
    Alpha阶段项目复审
    团队作业5——测试与发布（Alpha版本）
    团队作业四——七天的敏捷冲刺日志集合贴
    第 7 篇 Scrum 冲刺博客
  • 原文地址：https://www.cnblogs.com/tommyli/p/5064564.html
Copyright © 2011-2022 走看看