• 分布式事务


    参考:https://www.cnblogs.com/bluemiaomiao/p/11216380.html

    概念

    1. AP:资源管理器
    2. RM:资源管理器
    3. TM:事务管理器
    4. ACID:原子性、一致性、隔离性、持久性
    5. BASE理论:最终一致性
    6. CAP定理:C表示一致性,也就是所有用户看到的数据是一样的。A表示可用性,是指总能找到一个可用的数据副本。P表示分区容错性,能够容忍网络中断等故障

    服务模式

    1. 可查询操作:每个操作有唯一的标识、有操作时间
    2. 幂等操作:相同的业务重复调用,返回结果相同
    3. TCC操作:try/commit/cancel,try阶段检查并预留资源,commit阶段执行,cancel阶段取消,其中commit和cancel需要满足幂等操作;TCC是业务层面的,2PC是数据库层面的

    解决方案

    1. 基于可靠消息的最终一致性方案
      角色:服务A,服务B,可靠消息服务C,消息状态监测服务D
      流程:服务A发送请求到可靠消息服务C,服务C持久化成功后,标记待确认状态,返回成功状态给服务A,服务A处理完成后才确认,确认后消息会被发送给服务B;消息状态监测服务D定期找到未确认的消息去询问服务A是否有效,如果无效,则把消息清理掉;
      注意点:服务B需要满足幂等性;服务A需要提供消息状态回查接口;
    2. TCC事务补偿型方案
      角色:一个主业务服务A,多个从业务服务B,业务活动管理器C
      流程:主业务服务发A起请求给多个从业务B,从业务服务B分别检查当前资源是否满足,如果满足则预留资源;主业务服务发送确认状态给业务活动管理器C,由业务活动管理器C逐个发起commit给从业务服务B,如果其中一个commit失败,会逐个发起cancel操作;
      注意点:事务管理器需要做好日志记录;各个从业务服务都需要提供commit和cancel操作
      适用:金融账户或转账业务
    3. 最大努力通知型
      角色:主服务A,从服务B,中间消息载体C(可持久化)
      流程:服务A处理完成后,直接调用服务B,服务B定时向服务A查询,恢复丢失的消息,特点是允许消息丢失,被动方结果不影响主动方
      适用:对业务最终一致性的时间敏感度低,跨企业调用,如银行通知、商户通知
  • 相关阅读:
    Django创建超级用户出现错误
    如何创建单例设计模式
    运行Spark-shell,解决Unable to load native-hadoop library for your platform
    在linux上安装spark详细步骤
    Spark源码编译,官网学习
    linux安装httpd,做文件服务器
    在linux上安装Scala详细步骤
    hadoop运行wordcount实例,hdfs简单操作
    hadoop-2.6.0源码编译问题汇总
    hadoop-2.6.0源码编译
  • 原文地址:https://www.cnblogs.com/yinchh/p/12394341.html
Copyright © 2020-2023  润新知