1 关于分布式系统1.1 介绍我们常见的单体结构的集中式系统一般整个项目就是一个独立的应用所有的模块都聚合在一起。明显的弊端就是不易扩展、发布冗重、服务治理不好做。所以我们把整个系统拆分成若干个具备独立运行能力的计算服务的集合而从用户的角度看是一个完整的系统但实际上它是一个分布式服务的集合。分布式系统主要从以下几个方面进行裂变应用可以从业务领域拆分成多个module每个module还可以再按项目结构分成接口层、业务层、数据访问层当然也可以按访问入口进行拆分如移动、桌面、Web端访问的是不同的类型接口服务数据库可以按业务类型拆分成多个实例还可以对单库或单表进行分库分表参考我的这篇《分库分表》增加一些中间件来保证分布式系统的高可用如分布式缓存、搜索服务、文件服务、消息队列、非关系型数据库等中间件1.2 优势和不足分布式系统可以解决集中式不便扩展的弊端提供了便捷的扩展性、独立的服务治理并提高了安全可靠性。随着微服务技术Spring Cloud、Dubbo 以及容器技术Kubernetes、Docker的大热分布式技术发展非常迅速。不足的地方分布式系统虽好也带来了系统的复杂性如分布式事务、分布式锁、分布式session、数据一致性等都是现在分布式系统中需要解决的难题虽然已经有很多成熟的方案但都不完美。分布式系统的便利其实是牺牲了一些开发、测试、运维 成本的让工作量增加了所以分布式系统管理不好反而会变成一种负担。2 分布式事务分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式场景下一次完整的操作由不同的action组成这些actions可能分布在不同的服务器上且属于不同的应用分布式事务需要保证这些action要么全部成功要么全部失败。保证单个完整操作的原子性。本质上来说分布式事务就是为了保证不同数据库的数据一致性。2.1 CAP理论CAP 定理也称为 Brewer 定理指的是在分布式计算环境下有3个核心的需求1、一致性Consistency再分布所有实例节点同一时间看到是相同的数据2、可用性Availability不管是否成功确保每一个请求都能接收到响应3、分区容错性Partition Tolerance系统任意分区后在网络故障时仍能操作CAP理论告诉我们分布式系统不可能同时满足以下三种。最多只能同时满足其中的两项因为很多时候P是必须的, 因此往往选择就在CP或者AP中2.2 CAP的组合情况CA: 放弃分区容错性。非分布式架构比如关系数据库因为没有分区但是在分布式系统下CA组合就不建议了。AP: 放弃强一致性。追求最终一致性类似的场景比如转账可以接受两小时后到账Eureka的注册也是类似的做法。CP: 放弃可用性。zookeeper在leader宕机后选举期间是不提供服务的。类似的场景比如支付完成之后出订单必须一进一出都完成才行。结论在分布式系统中AP运用的最多因为他放弃的是强一致性追求的是最终一致性性价比最高2.3 数据一致性模型分布式系统通过同步数据的副本来提高系统的可靠性和容错性而且数据的不同的副本合理会存在不同的机器或集群上。强一致性当用户的操作完成之后会立马被同步到不同的数据副本中后续其他任意请求都会获得更新过的值。这种对用户的可见性是最友好的能始终保证读到正确的值。根据 CAP 理论这种实现需要牺牲可用性。弱一致性系统并不保证所有请求的访问都会获得最新值。数据写入成功之后不承诺立即可以读也不承诺具体多久之后可以读到甚至读不到。在请求获得数据更新的这段时间我i们称之为“不一致性窗口”。最终一致性是弱一致性的一种。系统保证在没有后续更新的前提下系统最终返回上一次更新操作的值。在没有故障发生的前提下不一致窗口的时间主要受通信延迟系统负载和复制副本的个数影响。常见的事务处理机制1、Master-Slave 复制写请求由 Master 负责写入 Master 后由 Master 同步到 Slave 上。异步同步所以是弱/最终一致性。2、Master-Master 主主复制异步同步最终的一致性多个节点间需要序列化协议。2.4 分布式事务应用场景2.4.1 典型支付场景这是最经典的场景。支付过程要先对买家账户进行扣款同时对卖家账户进行付款像这类的操作必须在一个事务中执行保证原子性要么都成功要么都不成功。但是往往买家的支付平台和卖家的支付平台不一致即使都在一个平台下所属的业务服务和数据服务归属不同表甚至不同库比如卖家中心库、卖家中心库也不是同一个。针对于不同的业务平台、不同的数据库做操作必然要引入分布式事务。2.4.2 在线下单同理买家在电商平台下单往往会涉及到两个动作一个是扣库存第二个是更新订单状态库存和订单一般属于不同的数据库需要使用分布式事务保证数据一致性。2.4.3 跨行转账跨行转账问题也是一个典型的分布式事务用户A同学向B同学的账户转账500要先进行A同学的账户-500然后B同学的账户500既然是不同的银行涉及不同的业务平台为了保证这两个操作步骤的一致分布式事务必然要被引入。2.5 常见分布式一致性保障分布式事务解决方案2.5.1 XA 两阶段提交协议两阶段提交协议Two-phase commit protocol简称2PC过程涉及到协调者和参与者。它是一种强一致性设计引入一个事务协调者的角色来协调管理各参与者的提交和回滚二阶段分别指的是准备投票和提交两个阶段。第一阶段准备阶段为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。在接到Prepare请求之后每一个参与者节点会各自执行与事务有关的数据更新写入Undo Log撤销和 Redo Log重做。如果参与者执行成功暂时不提交事务而是向事务协调节点返回“完成”消息。当事务协调者接到了所有参与者的返回消息整个分布式事务将会进入第二阶段。假如在第一阶段有一个参与者返回失败那么协调者就会向所有参与者发送回滚事务的请求即分布式事务执行失败。如下图:第二阶段提交阶段如果事务协调节点在之前所收到都是正向返回那么它将会向所有事务参与者发出Commit请求。接到Commit请求之后事务参与者节点会各自进行本地的事务提交并释放锁资源。当本地事务完成提交后将会向事务协调者返回“完成”消息。当事务协调者接收到所有事务参与者的“完成”反馈整个分布式事务完成。当有一个Commit 不成功那其他的应该也是提交不成功的。2.5.2 XA三阶段提交三阶段提交CanCommit 阶段、PreCommit 阶段、DoCommit 阶段简称3PC三阶段提交协议Three-phase commit protocol3PC是二阶段提交2PC的改进版本。与两阶段提交不同的是三阶段提交有两个改动点引入超时机制。同时在协调者和参与者中都引入超时机制。在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。即 3PC 把 2PC 的准备阶段再次一分为二这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。当 CanCommit、PreCommit、DoCommit的任意一个步骤失败或者等待超时执行RollBack。2.5.3 MQ事务利用消息中间件来异步完成事务的后半部分更新实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。下面的图中使用MQ完成事务在分布式的另外一个子系统上的操作保证了动作一致性。2.5.4 TCC事务TCC事务是Try、Confirm、Cancel三种指令的缩写其逻辑模式类似于XA两阶段提交但是实现方式是在代码层面人为实现。2PC 和 3PC 都是数据库层面的而 TCC 是业务层面的分布式事务。分布式事务除了上面提到的数据库层面的操作外还包括发送短信、邮件这种业务操作等这时候 TCC 就有用武之地了图中就是一个典型的分布式系统的原子性操作涉及A、B、C三个服务的执行。如果有一个服务 try 出问题整个事务管理器就执行calcel如果三个try都成功才执行confirm做正式提交。2.5.5 最终补偿机制同于MQ事务最后使用补偿机制做最后的一致性保障MQ方案尽量使用补偿机制进行保障。