610 天前 / 田守枝
点击上方"田守枝的技术博客"，关注我 提示：可能有人在公众号上看过这篇文章，这是我2018年2月份在我的博客上写的文章，现在搬到公众号上来，搬上来之前已经被其他公众号抄袭了，懒的投诉了。原创不易，且行且珍惜。 TCC的作用主要是解决跨服务调用场景下的分布式事务问题，在本文中，笔者将先介绍一个跨服务的场景案例，并分析其中存在的分布式事务问题；然后介绍TCC的基本概念以及其是如何解决这个问题的。 1 TCC简介关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an...
632 天前 / 廖君
1. 二阶段提交协议的由来 X/Open 组织提出了分布式事务处理的规范 DTP 模型(Distributed Transaction Processing)，该模型中主要定义了三个基本组件，分别是 应用程序(ApplicationProgram，简称AP)：用于定义事务边界(即定义事务的开始和结束)，并且在事务边界内对资源进行操作。 资源管理器(ResourceManager，简称RM)：如数据库、文件系统等，并提供访问资源的方式。 事务管理器(TransactionManager，简称TM)：负责分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚等。
639 天前 / 崴～～～
云湖湖导读： 在当今大数据时代，随着存储数据量的增长，对数据库插入与读取性能的要求越来越严苛。为了提升访问数据库的性能，已经有越来越多成熟的方案来并发访问数据库，Spark JDBC Datasource就是其中之一。而另一方面，并发访问数据库也会带来各种各样的问题，比如数据的保序、数据倾斜、并发一致性等问题。 本文将会从具体案例入手，通过以下3点来详细描述如何利用Spark来处理分布式事务，解决并发一致性问题。
640 天前 / 蚂蚁金服分布式架构SOFAStack
656 天前 / 蚂蚁金服分布式架构SOFAStack
上周，分布式事务 Fescar 宣布进行品牌升级： Thanks, Fescar ， Hello, Seata 。 Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。 项目地址：https://github.com/seata/seata 蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式，后续也会持续输入。 为了帮助大家理解，分布式事务开源负责人绍辉进行了一次线下分享，详细讲述了分布式事务在蚂蚁金服的发展，希望可以帮助大家理解，以下为分享的文字整理版本。
657 天前 / sjf0115
1. 概述在计算机网络以及数据库领域内，二阶段提交（Two-phase Commit）是指，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议。在分布式系统中，虽然每个节点可以知道自己的操作是成功还是失败，但却无法知道其他节点的操作是成功还是失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一协调所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
658 天前 / 咖啡拿铁
1.关于Seata再前不久，我写了一篇关于分布式事务中间件Fescar的解析，没过几天Fescar团队对其进行了品牌升级，取名为Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的Fescar的英文全称为Fast & EaSy Commit And Rollback。可以看见Fescar从名字上来看更加局限于Commit和Rollback，而新的品牌名字Seata旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。 这里先大概回忆一下Seata的整个过程模型: TM:事务的发起者。用来告诉TC，全局事务的开始，提交，回滚。
659 天前 / 深夜里的程序猿
前言 说到分布式事务的处理，可能是对与我们服务端开发人员来说是一个相当有挑战性的工作了，但是对于绝大部分开发人员，在他们的工作生涯中几乎接触不到相关的信息，第一是公司的技术业务或者技术达不到使用分布式事务的情况，还有一种情况是即使公司里面有用到，但是由于自己“受困于”业务的开发，而没办法去接触到。 那么我们是不是用不到就不用去了解呢？NO！作为一个技术人，必须保持对新鲜技术的饥渴度，机会总是留给有准备的人！不BB了，马上来看看吧。
667 天前 / 咖啡拿铁
1.分布式事务在去年的时候我写过一篇关于分布式事务的文章再有人问你分布式事务，把这篇扔给他。再这篇文章中我叫大家能不用分布式事务就别用分布式事务，因为会引入很多的复杂度。当时说这个的时候其实还有一个原因，没有大厂的成熟开源解决方案，虽然再网上有很多开源的分布式事务框架，但是都不是太成熟，没有大量的业务验证。它不像其他的分布式中间件有大量的成熟的解决方案，比如分布式消息队列中间件:Apache Kafka,Apache RocketMQ,Apache Pulsar这三个均是Apache顶级项目；又比如分布式任务调度...
671 天前 / zZhao
导读：微服务拆分之后，在很多场景，分布式事务无法避免。而分布式事务是行业内的一个技术难点，没有一种完美的方案。分布式事务有哪些解决方案？又应该如何落地？听京东数科数据研发负责人张亮讲述分布式事务的点点滴滴。本文适合研发工程师，技术经理，架构师反复阅读。 前文提到过，数据库事务是需要满足ACID（原子性、一致性、隔离性、持久性）四个特性的。 在单一数据节点中，事务仅限于对单一数据库资源进行访问控制，这种事务称为本地事务。几乎所有成熟的关系型数据库都提供了对本地事务的原生支持。
697 天前 / 忄落北
前言 一般，数据库事务的隔离级别会被设置成 读已提交，已满足业务需求，这样对应在Fescar中的分支（本地）事务的隔离级别就是 读已提交，那么Fescar中对于全局事务的隔离级别又是什么呢？如果认真阅读了 分布式事务中间件Txc/Fescar-RM模块源码解读 的同学应该能推断出来：Fescar将全局事务的默认隔离定义成读未提交。对于读未提交隔离级别对业务的影响，想必大家都比较清楚，会读到脏数据，经典的就是银行转账例子，出现数据不一致的问题。
704 天前 / 微服务蜂巢
点击蓝字关注我们 作者丨Willem Jiang 分布式事务协调场景介绍 在基于服务的分布式事务（上）中，我们举了一个业务场景的例子，就是一个初始服务创建了一个分布式事务，在这个分布式事务中包含了两个参与服务的本地事务，这两个本地事务由初始服务通过调用两个参与事务的服务方式组合在一起。根据分布式事务一致性的要求，这两个本地事务要么同时成功，要么同时失败。由于这两个参与事务的服务并不知道对方的存在，当一个参与服务调用（Invocation A）成功而另外一个参与服务调用（Invocation B）失败...
705 天前 / 君无戏言.
前言fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前，已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如LCN（https://github.com/codingapi/tx-lcn）的2pc型无侵入事务，目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等。
705 天前 / 微服务蜂巢
点小蓝字加关注！ 作者丨Willem Jiang 传统数据库事务 在传统单体应用架构下，我们通常会将业务数据存储在一个数据库中，应用各模块直接对数据库进行操作业务数据。由数据库提供基于ACID[1]的事务保证。 A是Atomic 原子性：事务作为整体来执行，要么全部执行，要么都不执行。 C是Consistency 一致性：事务应确保数据从一个一致的状态转变为另一个一致的状态。 I是 Isolation 隔离性：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 D是Durability 持久性：已提交的事务修改数据会被持久保持。