FESCAR

来源：http://dwz.date/eaAm 分布式事务是什么 数据库事务的特性包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabilily），简称 ACID。 在数据库执行中，多个并发执行的事务如果涉及到同一份数据的读写就容易出现数据不一致的情况，不一致的异常现象有以下几种。 脏读 ，是指一个事务中访问到了另外一个事务未提交的数据。例如事务 T1 中修改的数据项在尚未提交的情况下被其他事务（T2）读取到，如果 T1 进行回滚操作，则 T2 刚刚读取到的数据实际并不存在。 不可重复读 ，是指一个事务读取同一条记录 2 次，得到的结果不一致。例如事务 T1 第一次读取数据，接下来 T2 对其中的数据进行了更新或者删除，并且 Commit 成功。这时候 T1 再次读取这些数据，那么会得到 T2 修改后的数据，发现数据已经变更，这样 T1 在一个事务中的两次读取，返回的结果集会不一致。 幻读 ，是指一个事务读取 2 次，得到的记录条数不一致。例如事务 T1 查询获得一个结果集，T2 插入新的数据，T2 Commit 成功后，T1 再次执行同样的查询，此时得到的结果集记录数不同。 脏读、不可重复读和幻读有以下的包含关系，如果发生了脏读，那么幻读和不可重复读都有可能出现。 不同隔离级别 SQL 标准根据三种不一致的异常现象

前言 ​ 最近，工作中要为现在的老系统做拆分和升级，刚好遇到了分布式事务、幂等控制、异步消息乱序和补偿方案等问题，刚好基于实践结合个人的看法记录一下一些方案和思路。 分布式事务 首先，做系统拆分的时候几乎都会遇到分布式事务的问题，一个仿真的案例如下： 项目初期，由于用户体量不大，订单模块和钱包模块共库共应用（大war包时代），模块调用可以简化为本地事务操作，这样做只要不是程序本身的BUG，基本可以避免数据不一致。 后面因为用户体量越发增大，基于容错、性能、功能共享等考虑，把原来的应用拆分为订单微服务和钱包微服务，两个服务之间通过非本地事务操(这里可以是HTTP或者消息队列等)作进行数据同步，这个时候就很有可能由于异常场景出现数据不一致的情况。 事务中直接RPC调用达到强一致性 以上面的订单微服务请求钱包微服务进行扣款并更新订单状态为扣款这个调用过程为例，假设采用HTTP同步调用，项目如果由经验不足的开发者开发这个逻辑，可能会出现下面的伪代码： [订单微服务请求钱包微服务进行扣款并更新订单状态] 处理订单微服务请求钱包微服务进行扣款并更新订单状态方法(){ [开启事务] 1、查询订单 2、HTTP调用钱包微服务扣款 3、更新订单状态为扣款成功 [提交事务] } 这是一个从肉眼上看起来没有什么问题的解决方法，HTTP调用直接嵌入到事务代码块内部，猜想最初开发者的想法是

转：https://mp.weixin.qq.com/s/RYIiHAHHStIMftQT6lQSgA 做业务，要懂基本的SQL语句； 做性能优化，要懂索引，懂引擎； 做分库分表，要懂主从，懂读写分离... 数据库的使用，是开发人员的基本功，对它掌握越清晰越深入，你能做的事情就越多。 今天我们用10分钟，重点梳理一遍以下几方面： 数据库知识点汇总； 数据库事务特性和隔离级别； 详解关系型数据库、索引与锁机制； 数据库调优与最佳实践； 面试考察点及加分项。 一、数据库的不同类型 1.常用的关系型数据库 Oracle： 功能强大，主要缺点就是贵 MySQL： 互联网行业中最流行的数据库，这不仅仅是因为MySQL的免费。可以说关系数据库场景中你需要的功能，MySQL都能很好的满足，后面详解部分会详细介绍MySQL的一些知识点 MariaDB： 是MySQL的分支，由开源社区维护，MariaDB虽然被看作MySQL的替代品，但它在扩展功能、存储引擎上都有非常好的改进 PostgreSQL： 也叫PGSQL，PGSQL类似于Oracle的多进程框架，可以支持高并发的应用场景，PG几乎支持所有的SQL标准，支持类型相当丰富。PG更加适合严格的企业应用场景，而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。 2.NoSQL数据库（非关系型数据库） Redis： 提供了持久化能力

Fescar全局锁的理解 前几天夜里，我老大发我一篇文章说阿里的GTS开源了. 因为一直对分布式事务比较感兴趣。立马pull了代码，进行阅读。 基本的原理，实现方案我就不一一细化了，详细见官方文档（写的很棒，点赞）。 在fescar的社区，大家比较关注的是通过fescar回滚到before快照前，别的线程假如更新了数据，且业务走完了，那么恢复的这个快照不就是脏数据了么。 很显然，这种情况在fescar中是不被允许的。 那么fescar是如何做的呢？ 我们先简单了解一下fescar的设计原理 那些一上来就喜欢看源码的同学，一定不要错过这么官方的图文介绍，看完再读源码事半功倍. Fescar官方介绍 了解完Fescar的基本原理，我们重点关注下Fescar的全局排他锁 Fescar设计了一个**全局的排他锁**，来保证事务间的 **写隔离**。 关于隔离性：（这是Fescar官方给的一段话） 全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。 在数据库本地隔离级别 **读已提交或以上** 的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，来保证事务间的 写隔离，将 **全局事务默认定义在 读未提交 的隔离级别上**。 我们对隔离级别的共识是：绝大部分应用在读已提交的隔离级别下工作是没有问题的。而实际上，这当中又有绝大多数的应用场景

Fescar全局锁的理解 前几天夜里，我老大发我一篇文章说阿里的GTS开源了。 因为一直对分布式事务比较感兴趣，立马pull了代码，进行阅读。基本的原理，实现方案我就不一一细化了，详细见官方文档（写的很棒，点赞）。 在fescar的社区，大家比较关注的是通过fescar回滚到before快照前，别的线程假如更新了数据，且业务走完了，那么恢复的这个快照不就是脏数据了么。 很显然，这种情况在fescar中是不被允许的。 那么fescar是如何做的呢？ 我们先简单了解一下fescar的设计原理 那些一上来就喜欢看源码的同学，一定不要错过这么官方的图文介绍，看完再读源码事半功倍。 Fescar官方介绍（https://github.com/alibaba/fescar/wiki） 了解完Fescar的基本原理，我们重点关注下Fescar的全局排他锁 Fescar设计了一个全局的排他锁，来保证事务间的 写隔离。 关于隔离性：（这是Fescar官方给的一段话） 全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。 在数据库本地隔离级别 读已提交或以上 的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，来保证事务间的 写隔离，将 全局事务默认定义在 读未提交 的隔离级别上 。 我们对隔离级别的共识是：绝大部分应用在读已提交的隔离级别下工作是没有问题的。而实际上

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 划重点 2019 年公众号发布的文章共有 1452870 字，相当于 2 本《新华字典》 2019 年这些历程我们一起走过 1月 阿里巴巴李响入选 CNCF 技术监督委员会 9 人名单 阿里云成国内唯一入选 Gartner 公布《公有云容器服务竞争格局》报告企业 2月 阿里云开源 GPU Sharing，首次解决行业 GPU 资源共享调度痛点 3月 阿里云云原生产品家族公布，国内最全 蚂蚁金服加入阿里中间件开源分布式事务项目 Fescar，并贡献了 TCC 模式，Fescar 随即品牌升级为 Seata 4月 阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》正式上线 分布式任务调度平台 SchedulerX 2.0 公有云全面上线 阿里云链路追踪云产品正式商业化，提供基于 OpenTracing 规范的全链路追踪解决方案 阿里云消息队列 RabbitMQ 版正式商业化发布 5月 KubeCon EU 2019 在巴塞罗那举办，阿里巴巴共有 10 个技术演讲入选 Apache Dubbo 从 Apache 基金会孵化器毕业，成为顶级项目 阿里云 ARMS 云产品上线 Prometheus 监控云服务，国内首次推出云原生及周边生态的可观测性解决方案 阿里巴巴张乎兴成为 Apache

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> GTS 今年双 11 的成绩 今年 2684 亿的背后，有一个默默支撑，低调到几乎被遗忘的中间件云产品——GTS（全局事务服务，Global Transaction Service），稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。 2019 年 11 月 1 日至 12 日，GTS 日均处理分布式事务数量达 亿级 ，每天峰值 TPS 达 万级 。 这背后最重要意义在于：成绩是在给业务应用的设计和开发带来 0 负担 的前提下得到的。 GTS 带来的价值 随着企业的发展，企业业务架构面临数据、服务的分布化，几乎无可避免地要遇到分布式架构带来的数据一致性问题。 GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。 GTS 给业务应用带来的价值体现在以下几个方面： 架构复杂度降低：分布式事务这个 切面 的技术问题，全部 收敛 到 GTS 提供的服务来解决。 设计和开发成本减轻：业务逻辑的设计和开发，完全不需要针对是否涉及分布式事务而做任何额外的事情，对业务 0 侵入 。 项目交付、迭代速度加快：归因于上述两点，项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力，在这个商业机会瞬息万变的时代

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1.关于Seata 再前不久，我写了一篇关于分布式事务中间件Fescar的解析，没过几天Fescar团队对其进行了品牌升级，取名为Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的Fescar的英文全称为Fast & EaSy Commit And Rollback。可以看见Fescar从名字上来看更加局限于Commit和Rollback，而新的品牌名字Seata旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。 这里先大概回忆一下Seata的整个过程模型: TM:事务的发起者。用来告诉TC，全局事务的开始，提交，回滚。 RM:具体的事务资源，每一个RM都会作为一个分支事务注册在TC。 TC:事务的协调者。也可以看做是Fescar-servr，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色TC，也就是事务协调器。 2.Transcation Coordinator 为什么之前一直强调TC是核心呢？那因为TC这个角色就好像上帝一样，管控着云云众生的RM和TM。如果TC一旦不好使，那么RM和TM一旦出现小问题，那必定会乱的一塌糊涂

来源： https://my.oschina.net/qwfys200/blog/3111671

Photo @ https://danielbachhuber.com/ 文 | 白科 有人问： 开源是为了什么？ 这里有一些大家能在网上找到的参考答案。 从个人的视角看 参与开源 可以证明自己的 专业能力 并在行业内获得 认可 释放自己的 兴趣爱好 ⇣ 从企业的视角看 可以建立 技术影响力 对 招聘 、建立商业化 竞争优势 都有帮助 ⇣ 当然还有更 经济学的说法 开源作为一种 生产协作模式 大幅提升了商品的 生产效率和分发效率 阿里巴巴中间件 这一服务号 自去年6月15日发布第一篇文章开始 随着阿里巴巴的一系列微服务开源项目 一起成长 （点击了解成长之路） Dubbo Rocket MQ Sentinel Nacos Arthas Spring Cloud Aliabba Seata ChaosBlade ... 正如您第一次订阅我们时 接收到的自动回复 破土而出的生命力，源自理想主义者心底对技术的信念 我们 尝试把对技术的 情怀、实践 以文字的形式 进行表达和传播 由此聚集了不少的开发者 他们正通过这些开源项目构建自己的微服务架构 还有不少人加入社区， 参与 开源共建 让技术变得更好 为表感谢 2019 年 8 月 12 日 我们向 1349 位社区开发者送出了定制礼品 例如 这是来自 Seata 社区的通知邮件 同时 我们也采访了几位开源贡献者 看看他们是如何看待 开源的