SAGA

前言 说到分布式事务，大部分人都会知道ACID，两阶段提交，TCC等常见模式。 在微服务大行其道的今天，基于Saga实现的分布式事务则更具普适性。 微服务事务 微服务是将服务粒度控制在上下文内的松耦合的服务架构。对于微服务架构的事务建议对于数据库提供强一致的事务，在服务上下文之间依靠最终一致性方案来解决服务之间协同的问题。 Saga saga是30年前的一篇数据库论文提到的概念。 论文中定义 saga事务是一个长事务，整个事务可以由多个本地事务组成，每个本地事务有相应的执行模块和补偿模块，当saga事务中任意一个事务出错了，可以调用相关事务进行对应的补偿恢复，达到事务的最终一致性 。 幂等 由于分布式系统中网络带来的不可靠性，saga调用服务提出了服务应该支持幂等，在服务调用超时重试情况下，不至于产生问题。 隔离性 saga事务没有准备阶段，不具备隔离性，如果多个saga事务同时操作同一资源会遇到多线程临界资源的情况，产生数据丢失或者脏数据。 为解决隔离性，可以参考TCC模式，在业务层加入session及锁机制保证操作串型化，通过业务层面达到隔离效果。 事件 saga在分布式架构下，采用事务驱动方式，让服务进行相关交互，业务方订阅相关领域事件即可。 通过事件方式降低系统复杂度，提升系统扩展性，但要注意事件循环依赖的问题。 Saga事务框架实现 组成部分： 服务发现模块

[TOC] 更新、更全的《机器学习》的更新网站，更有python、go、数据结构与算法、爬虫、人工智能教学等着你：<a target="_blank" href="https://www.cnblogs.com/nickchen121/p/11686958.html"> https://www.cnblogs.com/nickchen121/p/11686958.html </a> scikit-learn库之逻辑回归 相比较线性回归，由于逻辑回归的变种较少，因此scikit-learn库中的逻辑回归类就比较少，只有 LogisticRegression 、 LogisticRegressionCV 和 logistic_regression_path 。 接下来将会讨论这三者的区别，由于是从官方文档翻译而来，翻译会略有偏颇，有兴趣的也可以去scikit-learn官方文档查看 https://scikit-learn.org/stable/modules/classes.html#module-sklearn.linear_model ，需要注意逻辑回归和线性回归都在 sklearn.linear_model 包中。 一、LogisticRegression 1.1 使用场景 逻辑回归一般使用于分类场景，可以使用参数让普通的二元分类问题变成多分类问题。 1.2 代码 from

- 总述 - 咱们前面分别对分布式事务的几个分支：XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇，讲对前面的内容查缺补漏和总结，最后对市面的一些开源框架做一些介绍。 - 查缺补漏 - 1. 补偿型事务 柔性事务分补偿型事务和通知型事务。但对补偿型事务没有进行详细介绍，那什么是补偿型事务呢，在Atomikos 公司Guy Pardon的论文 《Business_Activities》 中有这样的描述： 大致含义是， "补偿是一个独立的支持ACID特性的本地事务，用于 在逻辑上取消了先前 ACID交互的影响。对于一个长事务来说，基于补偿的方法可将事务资源锁定时间保持在最低程度，从而避免了事务资源长期占用等缺点。”。 2. TCC事务模型补充 咱们前面文章说了不推荐TCC，并且认为Seata的AT模式从理论上来说更像是Saga的变种，而非TCC的变种。目前有很多资料自行将TCC分了几个分支： 通用型TCC：标准TCC模型实现，从业务服务需要提供Try、Confirm、Cancel 补偿性TCC：子服务只需要提供 Do 和 Compensate 两个接口 异步确保型TCC：主服务是可靠消息服务，而子服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。可靠消息服务需要提供 Try、Confirm、Cancel 三个接口

- 消息详解 - 一、概述 在 《柔性事务之TCC详解》 和《柔性事务之Saga详解》两文中我们详细剖析了柔性事务的第一个分支补偿型事务。在《刚性事务总结和柔性事务概述》中我们介绍过的柔性事务包含补偿型事务和通知型事务。 通知型事务主要包含事务消息和最大努力通知型分布式事务两个组成。通知型事务的核心思想是通过MQ来通知其他事务参与者自己事务的执行状态。MQ组件的引入有效的将事务参与者解耦开，各个参与者都可以异步执行，所以通知型事务又称为异步事务。 事务消息的难度在于服务本地事务和投递消息的一致性保障。目前业界解决这个一致性的方案有两个分支： 基于MQ自身的事务消息方案 基于DB的本地消息表方案 - 基于MQ自身的事务消息方案 - 基于MQ的事务消息方案主要依靠MQ的半消息机制来实现投递消息和参与者自身本地事务的一致性保障。半消息机制实现原理其实借鉴的2PC的思路，是二阶段提交的广义拓展，流程图如下： 1、事务发起方首先发送prepare消息到MQ； 2、在发送prepare消息成功后执行本地事务； 3、根据本地事务执行结果返回commit或者是rollback； 4、如果消息是rollback, MQ将删除该prepare消息不进行下发，如果是commit消息，MQ将会消息发送给consumer端； 5、如果执行本地事务过程中，执行端挂掉，或者超时

事务消息介绍 事务消息貌似是阿里提出的分布式事务解决方案，依赖于RocketMQ的事务消息实现（ RocketMQ事务消息 ）。 其核心是通过MQ类似于DB的事务提交或回滚功能+MQ主动回查机制(MQ请求应用)来确保最终的消息确认动作。 它的实现原理也比较简单，我们可以基于上一篇“ 分布式事务（四）：本地消息表 ”对照理解。 在本地消息表实现方案中，由于MQ不支持(或者不使用)事务，我们无法确保最终消息投递结果和数据库事务是否保持一致，所以加入了定时任务+本地消息表来进行消息重发机制保障最终一致性。 但是这样使每个服务都存在定时任务和消息表，导致代码逻辑以及数据库表设计和业务耦合严重；所以在事务消息中，将这一部分功能交给MQ进行实现。 MQ事务消息 RocketMQ是支持事务的，其实现原理也是二阶段提交。 也就是说我先发起一个发送消息的动作，但是这个动作类似于db中的声明了一个事务并执行了sql，此时并没有确认提交或者回滚。 然后进行业务处理，处理成功这提交，失败则回滚。 事务消息的回查机制 事务消息回查机制是指，假设客户端发起了一个发送消息的动作，但是后续没响儿了；那MQ怎么办呢，也不能傻等着。 所以MQ就主动的请求服务发起方，来进行询问；这个就是回查机制。 回查机制需要服务发起方进行接口的提供。 事务消息模型 这里画了一个事务消息大致流程： 我们跟着图来解读一下：

前几天，一位妈妈在后台发了一道数学习题（是的，你们的言我都会看）。小学一二年级的回家作业，大门解的时候竟然还卡了一下。 >>>> 真不知道当年自己的高等数学是怎么过的，回想起来，大学数学课好像全用来通关Candy Crush Saga（糖果粉碎传奇）了。???? 所以，当听说有一个“数学建造的房子”的时候，大门的内心是拒绝的，微积分、线性代数又要来虐我了吗，我不看我不看????。 然而…… 提到数学家， 我以为是这样的： 发际线不低，面部表情匮乏， 总爱是写外星符号。 然而却是这样的， 刚刚还在讲sin、cos, 一转头就掏出一把小提琴， 超高难度的帕格尼尼随想曲说来就来。 数学家的家， 我以为是这样的： 到处都是方便食品， 颜色搭配看心情，装修看运气。 就是想拉《生活大爆炸》出来遛一下 然而却是这样的， 优雅的曲线细细地勾勒边框， 磨砂玻璃和实木的简洁搭配， 柔和、精准的灯光设计。 没错，这个看上去又美又贵的建筑不是博物馆也不是剧院，只是一个数学家的私人住宅。 他叫James Stewart，没听过？不要紧，如果你的大学数学课用的是英文教材，那么你八成已经见过他的名字一千八百遍了，尤其是期末考之前。 这本虐你如初恋的微积分教材（Single Variable Calculus: Early Transcendentals）就是他写的。 这本书以极高的习题质量和严谨行文闻名于世

作者 | 陈健斌（funkye） github id: a364176773 来源| 阿里巴巴云原生公众号 Seata 是一款开源的分布式事务解决方案，star 高达 18100+，社区活跃度极高，致力于在微服务架构下提供高性能和简单易用的分布式事务服务，本文将剖析 Seata-AT 的实现原理，让用户对 AT 模式有更深入的认识。 Seata 事务模式是什么? 1. Seata 对事务的定义 Seata 定义了全局事务的框架。 全局事务定义为若干分支事务的整体协调： TM 向 TC 请求发起（Begin）、提交（Commit）、回滚（Rollback）全局事务。 TM 把代表全局事务的 XID 绑定到分支事务上。 RM 向 TC 注册，把分支事务关联到 XID 代表的全局事务中。 RM 把分支事务的执行结果上报给 TC。（可选） TC 发送分支提交（Branch Commit）或分支回滚（Branch Rollback）命令给 RM。 Seata 的全局事务处理过程，分为两个阶段： 执行阶段 > ：执行分支事务，并保证执行结果满足是可回滚的（Rollbackable）和持久化的（Durable）。 完成阶段 > ：根据执行阶段结果形成的决议，应用通过 TM 发出的全局提交或回滚的请求给 TC，> TC 命令 RM 驱动 分支事务 进行 Commit 或 Rollback。

本次发布主提供多库和微服务事务支持，使用了 BeetlSQL 的自带的 Saga 实现 新增多库和微服务 Saga 实现 修复代码生成因为重构带来的问题 Saga文档 Maven <dependency> <groupId>com.ibeetl</groupId> <artifactId>beetlsql</artifactId> <version>3.2.0-RELEASE</version> </dependency> Saga 初期是长事务的解决方案，微服务流行后也可以为微服务提供事务解决方案。不同于传统的数据库事务或者 2 阶段提交，必须·依赖于数据库系统实现 ACID 事务，Saga 不依赖于特定系统（实际上也不可能让所有系统实现 ACID，比如 Redis，Mongdb），只要求特定系统能提供补偿操作，在出错的时候能执行补偿操作即可。因此可以很方便用在现代的微服务架构中。 一个长事务的例子，如订购电影票，分为选座位和支付俩个步骤。用户可能会花好几分钟才能能完成。另一个例子是下单旅游产品，需要酒店，飞机，旅行社各个系统协作。 关于Saga，我认为最好的文章是 https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga，因为他即告诉你什么是Saga

这是“领域驱动设计实践之路”系列的第四篇文章，从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构的思想，以实际使用场景为背景，展示了一个微服务的程序结构设计。 一、单体架构的弊端 单体结构示例(引用自互联网) 一般在业务发展的初期，整个应用涉及的功能需求较少，相对比较简单，单体架构的应用比较容易部署、测试，横向扩展也比较易实现。 然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。 下面分析下单体架构应用存在的一些弊端： 1、复杂性高 在项目初期应该有人可以做到对应用各个功能和实现了如指掌，随着业务需求的增多，各种业务流程错综复杂的揉在一起，整个系统变得庞大且复杂，以至于很少有开发者清楚每一个功能和业务流程细节。 这样会使得新业务的需求评估或者异常问题定位会占用较多的时间，同时也蕴含着未知风险。更糟糕的是，这种极度的复杂性会形成一种恶性循环，每一次更改都会使得系统变得更复杂，更难懂。 2.技术债务多 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。比如，团队必须长期使用一套相同的技术栈，很难采用新的框架和编程语言。有时候想引入一些新的工具时