mcs site

CAP定理

什么是CAP定理

  • Consistency 一致性
  • Availability 可用性
  • Partition tolerance 分区容忍度

C

服务期间数据一致性

A

服务节点收到请求，在合理时间做出相应

P

分区容忍度，当通信出现故障，仍能正常提供服务 一致性 C 需要锁定资源惊醒同步 可用性 A 要求合理事件做出相应 C和A是互斥的

CAP 难题

  • 容错性P无法避免，分布式系统通常 A > C
  • PA满足，比如导致一致性难题
  • 分布式系统不可能100%保证一致性，都是尽可能保证成功率
  • 分布式事务是解决一致性的一种解决方案，通常是 "保证最终一致性"

一致性分类

  • 强一致性： 数据必须完全一致，中间过程不可见，同步完成
  • 弱一致性： 运行部分一致性，中间过程可见，异步完成
  • 最终一致性： 过一段事件后，保证数据完全一致

XA 与 JTA

JTA 依托与 J2EE容器

第一阶段 创建事务不提交

image-20201218110508561

第二阶段 提交。如果一阶段有服务超时或失败，就会对所有服务进行回滚

image-20201218110544459

  • XA 是 X/Open 组织提出的分布式事务规范、
  • XA 采用两阶段方案(Pre, Commit)
  • JTA(Java Transaction API)J2EE模块，定义Java的XA接口
  • J2EE 容器(Weblogic,JBoss) 是JTA的实现

JTA问题

  • 同步阻塞，并发效率差
  • 分布式架构存在瓶颈
  • 脑裂，无法保证数据一致性(提交阶段，J2EE 容器无法知道微服务是否提交成功)
  • 数据源类型受限

TCC

  • TCC 是 Try（尝试），Confirm（确认）， Cancel（取消）
  • Try 尝试阶段，对资源进行锁定
  • Confirm 确认阶段，对资源进行确认，完成操作
  • Cancel 取消阶段，对资源进行还原，取消操作

尝试

image-20201218111511810

确认

image-20201218111613497

取消

image-20201218111634707

如何保证最终一致性

  • TCC认为Confirm和Cancel一定成功
  • Confrim和Cacel尽可能不要产生服务通信
  • Confrim和Cancel如果失败,TCC框架进行重试补偿
  • C/C彻底失败，需要定时任务检查或人工介入
Last Updated:
Contributors: himcs