事务-06-分布式事务实现模式与技术

时间 2019-12-07

标签事务分布式实现模式技术栏目快乐工作繁體版

原文原文链接

1 、三种模式git

消息驱动模式：Message Driven
事件溯源模式：Event Sourcing
TCC模式：Try-Confirm-Cancel

二、消息驱动（Message Driven）github

2.1 微服务架构的事务问题数据库

服务间调用操做的回滚
服务间调用失败的重试问题

2.2 微服务架构的事务问题解决网络

减小服务间调用
没有服务间调用，经过消息驱动调用服务

2.3 注意的问题架构

消息中间件须要支持事务
如何处理重试的消息
发生业务异常时回滚操做

2.4 系统错误的处理框架

将出错未处理的消息写到失败队列，进行相应回滚操做
经过定时任务检查超时订单，对未完成的订单作自动回滚
报错出错消息，人工处理

3 事件溯源（Event Sourcing）分布式

3.1 msg-driven or event driven微服务

事件不要求持久化保存
消息只是为了更新业务数据的状态，数据库才是一等数据
不要求全部的数据操做都经过消息驱动

3.2 事件溯源（event-sourcing）性能

事件做为一等数据保存
统一的事件管理器和接口，数据更新都由事件产生
数据库中数据的当前状态根据事件的聚合产生
聚合数据能够保存在数据库中、能够根据时间从新生成

3.3 事件溯源优势学习

历史重现：从事件中从新生成视图数据库
方便的数据流处理与报告生成
性能（？）
服务的耦合

3.4 事件溯源缺点

只能保证事务的最终一致性
设计和开发思惟的转变、学习成本
事件结构的改变
扩展性：Event Store的分布式实现，事件的分布式处理

3.5 消息驱动vs事件溯源

一等数据：事件 VS 业务数据
事件永久保存、历史重现
全部数据更新都必须经过事件产生
Event Sore服务承担更多的功能

3.6 事件溯源的数据一致性

一个事件只处理一个服务的数据
保证事件的至少一次处理、幂等性
业务请求的错误处理：屡次重试失败、网络异常、服务不可用

3.7 事件溯源和CQRS

CQRS：命令查询职责分离
C端执行命令，Q端执行查询

3.8 使用Axon框架的设计过程

领域模型：帐户Account
业务Command：建立帐户、存款、取款
事件Event：帐户建立、存款、取款
将帐户信息保存到数据库中，方便查询
查询Command：查询帐户

4 TCC模式(Try-Confirm/Cancel)

4.1 传统事务管理过程

do
commit/rollback

4.2 JTA事务管理过程

do
prepare / rollback
commit / rollback

4.3 TCC模式事务管理过程

Try
Commit（Confirm）/ Cancel

4.4 TCC模式协调器的功能

接管事务管理，相似JTA的独立事物管理器（非两阶段提交）
保存每一个资源上的事务记录：跟踪状态、检查超时
保证每一个资源上的事务性
处理各类错误：超时、重试、网络异常、服务不可用

4.5 TCC模式实现分布式事务

借鉴XA的统一资源管理，又不是两阶段提交
不一样资源之间没有锁，事务过程数据没有锁、没有隔离
出错时可能屡次调用Confirm / Cancel方法、以及顺序没法保证
Confirm/Cancel方法须要知足幂等性，即重复调用时结果一致

4.6 TCC模式实现思路，Service规范（没有现成的框架）

将一个业务逻辑封装成TccMethod类来调用
协调器保存TccMethod、TccRequest、TccResponse
服务会有一个专门的接口接收协调器的请求，处理Confirm / Cancel
服务不须要开放Cofirm/Cancel的接口

4.7 基于TCC模式开发的注意事项

合理设计try/confirm/cancel方法的功能
保证confirm/cancel方法的幂等性
设计合理的服务间调用：try方法能够调用其余服务

4.8 基于TCC模式的开发

没有统一的规范，也没有普遍使用的框架
协调器的开发比较复杂：须要保证各类出错状况下的最终一致性
协调器监控事务：事务及其参数、返回值保存在数据库中
TCC模式的服务组件的复用性

4.9 实现TCC模式的框架

实现服务接口规范、协调器，git上笔记好的实现

https://github.com/liuyangming/ByteTCC
https://github.com/QNJR-GROUP/EasyTransaction
https://github.com/changmingxie/tcc-transaction