分布式一致性

一 什么是事务？有什么用？ 事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。 2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。 3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的 事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。 4）持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变 就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 二 事务的并发会产生的问题有哪些 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 一个事务多次读取同一个数据，在该事务还未结束时，另一个事务也对该数据进行 了操作，而且在第一个事务两次读取之间，第二个事务对数据进行了更新，那么第一个

基本概念 本地事务 事务由资源管理器（如DBMS）本地管理 优点：严格的ACID 缺点：不具备分布事务处理能力 全局事务（DTP模型） TX协议：应用或应用服务器与事务管理器的接口 XA协议：全局事务管理器与资源管理器的接口 优点：严格的ACID 缺点：效率非常低 两阶段提交 优点 准备后，仍可提交或回滚 准备时，一致性检查必须OK 准备后，事务结果仍然只在事务内可见 准备后，事务结果已经持久化 缺点： 潜在故障点多带来的脆弱性 准备后，提交前的故障引发一系列隔离与恢复难题 http://book.51cto.com/art/201309/410608.htm 跨域的全局事务（DTP模型） 缺点 更高的协议成本 脆弱，故障点多 故障影响大，恢复困难 复杂，更多架构与平台约束 java企业平台中的分布式事务实现 JTA 面向应用、应用服务器与资源管理器的高层事务接口 JTS JTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性 EJB 优点 简单一致的编程模型 跨域分布处理的ACID保证 局限 DTP模型本身的局限 缺少充分公开的大规模、高可用、密集事务应用的成功案例 JMS与分布式事务： http://techv5.com/topic/1371/ 其它资源 ws-transaction标准 jbossTransaction系统 Paxos算法

背景 LCN框架在2017年6月份发布第一个版本，从开始的1.0，已经发展到了5.0版本。 LCN名称是由早期版本的LCN框架命名，在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名。 锁定事务单元（lock） 确认事务模块状态(confirm) 通知事务(notify) 5.0以后由于框架兼容了LCN、TCC、TXC三种事务模式，为了避免区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务框架。 框架定位 LCN并不生产事务，LCN只是本地事务的协调工 TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。 解决方案 在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。 例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。 方案： 若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。 入门 随着互联化的蔓延，各种项目都逐渐向分布式服务做转换

1. CAP理论 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。 CAP理论为：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 1.1 一致性（Consistency） 一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。 1.2 可用性（Availability） 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。 1.3 分区容错性（Partition tolerance） 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 2. CAP权衡

关于分布式事务，工程领域主要讨论的是强一致性和最终一致性的解决方案。典型方案包括： 两阶段提交（2PC, Two-phase Commit）方案 eBay 事件队列方案 TCC 补偿模式 缓存数据最终一致性 一、一致性理论 分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性宕机，像单机事务一样的ACID是无法奢望的。另外，业界著名的CAP理论也告诉我们，对分布式系统，需要将数据一致性和系统可用性、分区容忍性放在天平上一起考虑。 两阶段提交协议（简称2PC）是实现分布式事务较为经典的方案，但2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师Dan Pritchett 提出了BASE 理论，用于解决大规模分布式系统下的数据一致性问题。BASE 理论告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。 1、CAP理论 在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。 <img src="https://pic4.zhimg.com/v2-8bb62ba9e7ce9f35199da032e17f9bb7_b.png" data-rawwidth=

分布式系统理论基础 - CAP 12513 0 收藏 编辑 引言 CAP是分布式系统、特别是分布式存储领域中被讨论最多的理论，“ 什么是CAP定理？ ”在Quora 分布式系统分类下排名 FAQ 的 No.1。CAP在程序员中也有较广的普及，它不仅仅是“C、A、P不能同时满足，最多只能3选2”，以下尝试综合各方观点，从发展历史、工程实践等角度讲述CAP理论。希望大家透过本文对CAP理论有更多地了解和认识。 CAP定理 CAP由 Eric Brewer 在2000年PODC会议上提出 [1][2] ，是Eric Brewer在Inktomi [3] 期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想： It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance. 该猜想在提出两年后被证明成立 [4] ，成为我们熟知的CAP定理： 数据一致性 (consistency)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败

CAP理论 小结： Consistency 一致性 就是数据的一致性。一致性根据时间长短来达到一致性，又分为 强，弱，最终一致性 Availability 可用性 可用性是针对用户角度，发送一个请求，一定回复。保证这一点就是可用性 分区容错性 就是分布式节点中 某一个节点挂了，系统还能满足一致性和可用性 CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。 CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。 AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。 因为 AP更为重要 所以一般都是C，使用最终以执行 版权 我仅对文章的排版和部分文字进行了润色 2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy

数据一致性的问题 目前基本生产环境中后台系统都是分布式系统，比如说一个网络变更（配置文件或者其他内容）如何在分布式网络中得到一致的执行结果，这是一个问题。 cap原理及一致性算法分类 在2000年 Principles of Distributed Computing大会上Eric Brewer发表了CAP理论。在2002年, Seth Gilbert和Nancy Lynch发表了更加正式的CAP理论论证。 cap原理中，有三个要素： 1. 一致性（Consistency） 2. 可用性（Availablity） 3. 分区容忍性（Partition Tolerance） 分布式系统只能满足其中两个要素。对于分布式说系统而言，分区容忍性是基本要求，设计分布式系统就是在一致性及可用性中取一个平衡。有两种衡量一致性的方式，客户端一致性：从开发者/客户端的角度：他们如何观察数据更新。服务器端一致性：从服务器端的角度：更新时如何流经系统，和系统对更新有和保证。 客户端一致性 1. 强一致性：在更新操作完成之后，任何后续的访问将返回更新的值。 2. 弱一致性：系统不能保证后续访问返回更新的值。需要在一些条件满足之后，更新的值才能返回。从更新操作开始，到系统保证任何观察者总是看到更新的值的这期间被称为不一致窗口。 3. 最终一致性：这是弱一致性的特殊形式

C onsistency 一致性 A vailability 可用性(指的是快速获取数据) P artition 分区容忍性(分布式) 10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。如果你 关注的是一致性，那么您就需要处理因为系统不可用而导致的操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。 作为架构师，一般有两个方向来利用CAP理论 key-value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。 我准备提供第三种方案：实现可以配置CAP的数据库，动态调配CAP。 CA

事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 3.幻读 第一个数据正在查询某一条数据，这时，另一个事务又插入了一条符合条件的数据，第一个事务在第二次查询符合同一条件的数据时，发现多了一条前一次查询时没有的数据，仿佛幻觉一样，这就是幻读 不可重复读是指在同一查询事务中多次进行，由于其他提交事务所做的修改和删除，每次返回不同的结果集，此时发生不可重复读 幻读是指在同一查询事务中多次进行，由于其他提交的事务所做的插入操作，每次返回不同的结果集，此时发生幻读表面上看，区别就在于不可重复读能看见其他事务提交的修改和删除，而幻读能看见其他事务提交的插入 1.default：(默认) 默认隔离级别，使用数据库默认的事务隔离级别 2.read_uncommitted:(读未提交) 这是事务最低的隔离级别,他允许另外一个事务可以看到这个事务未提交的数据,这种隔离级别会产生脏读