分布式一致性

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

1 分布式概述 早起我们使用单体架构，即所有的服务都部署在一台服务器的一个进程中，随着互联网的发展，逐步演进为分布式架构，多个服务分别部署在不同机器的不同进程中。 2 Zookeeper概述 Zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理分布式锁、分布式队列等功能。 Zookeeper提供了分布式数据一致性的解决访问，那么什么是分布式数据一致性？ 如上图所示，有用户user在DB1中修改balance为900，如果user下一次read请求到DB2数据库的时候，此时DB1数据库的数据还没及时更新到DB2中，就会造成整个数据库集群数据不一致。 数据一致性分为强一致性和最终一致性，强一致性指的是如果数据不一致，就不对外提供数据服务，保证用户读写的数据始终是一致的。数据强一致性值需要通过锁机制即可解决，在案例中通过在DB2没有从DB1同步数据之前上锁，不对外提供读操作。只要当同步完成以后才对外提供服务。而最终一致性要求数据最终同步即可，没有实时要求。 3 CAP原则 CAP在分布式系统中主要指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。 一致性：一致性指的就是强一致性。 可用性：系统提供的服务一直处于可用状态

今天的文章咱们聊的是分布式原理当中的 原子性 ，也称为 分布式事务 。不知道会不会有人觉得奇怪，分布式系统CAP原则当中并没有原子性，这个原子性是从哪里冒出来的？ 其实并不奇怪，之前我们在介绍各种一致性原则的时候，虽然没有明确提出来，但是原子性的相关内容已经隐藏在其中了。让我们回顾一下，分布式系统当中的一致性简单可以分为 强一致性和弱一致性 。强一致性很好理解，简单可以理解成 主节点每次更新都通过同步的方式，同步更新所有副本 。而弱一致性则是统称所有不满足强一致性的模型，可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候，有节点出错的情况。如果是强一致性，很好办，因为我们采用同步更新，所以更新失败的话，主节点立刻就能感知。要么 重试这次的更新 ，要么 回滚放弃 ，或者是 判断该从库是否已经宕机 ，将它 移除资源池 。 如果是异步的更新机制就麻烦了，因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没有 ，如果部分成功了，部分失败了，那么数据的一致性就完全没办法保障了，脏数据到处都是，这个系统也就没法用了。所以必须要保证即使是异步更新，也要做到原子性，要么所有节点一起更新成功，要么一起失败回滚，不允许出现一部分成功了，另一部分没有的情况。 那么怎么解决这个问题呢？这就需要用到 两阶段提交协议 了。 两阶段提交 两阶段提交协议的算法思路其实不难

本文始发于个人公众号： TechFlow 今天的文章咱们聊的是分布式原理当中的 原子性 ，也称为 分布式事务 。不知道会不会有人觉得奇怪，分布式系统CAP原则当中并没有原子性，这个原子性是从哪里冒出来的？ 其实并不奇怪，之前我们在介绍各种一致性原则的时候，虽然没有明确提出来，但是原子性的相关内容已经隐藏在其中了。让我们回顾一下，分布式系统当中的一致性简单可以分为强一致性和弱一致性。 强一致性 很好理解，简单可以理解成 主节点每次更新都通过同步的方式，同步更新所有副本 。而 弱一致性 则是统称所有不满足强一致性的模型，可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候，有节点出错的情况。如果是强一致性，很好办，因为我们采用同步更新，所以更新失败的话，主节点立刻就能感知。要么 重试这次的更新 ，要么 回滚放弃 ，或者是 判断该从库是否已经宕机 ，将它 移除资源池 。 如果是异步的更新机制就麻烦了，因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没 有，如果部分成功了，部分失败了，那么数据的一致性就完全没办法保障了，脏数据到处都是，这个系统也就没法用了。所以必须要保证即使是异步更新，也要做到原子性，要么所有节点一起更新成功，要么一起失败回滚，不允许出现一部分成功了，另一部分没有的情况。 那么怎么解决这个问题呢？这就需要用到 两阶段提交协议 了。

高并发服务端 分布式系统设计概要（上） ======张峻崇 原创。转载请注明出处。====== 又是快一年没写博客了，2013年也只剩尾巴，也不知道今年都忙了些什么。写这篇文章的目的，主要是把今年以来学习的一些东西积淀下来，同时作为之前文章《高性能分布式计算与存储系统设计概要》的补充与提升，然而本人水平非常有限，回头看之前写的文章也有许多不足，甚至是错误，希望同学们看到了错误多多见谅，更欢迎与我讨论并指正。 好了，下面开始说我们今天要设计的系统。 这个系统的目标很明确，针对千万级以上PV的网站，设计一套用于后台的高并发的分布式处理系统。这套系统包含业务逻辑的处理、各种计算、存储、日志、备份等方面内容，可用于类微博，SNS，广告推送，邮件等有大量线上并发请求的场景。 如何抗大流量高并发？（不要告诉我把服务器买的再好一点）说起来很简单，就是“分”，如何“分”，简单的说就是把不同的业务分拆到不同的服务器上去跑（垂直拆分），相同的业务压力分拆到不同的服务器去跑（水平拆分），并时刻不要忘记备份、扩展、意外处理等讨厌的问题。说起来都比较简单，但设计和实现起来，就会比较困难。以前我的文章，都是“从整到零”的方式来设计一个系统，这次咱们就反着顺序来。 那我们首先来看，我们的数据应该如何存储和取用。根据我们之前确定的“分”的方法，先确定以下2点： （1）我们的分布式系统，按不同的业务，存储不同的数据

目录 事务简介 事物的定义 事务的目的 事务的状态 事务的ACID属性 ACID简介 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） 总结 参考文献 版权声明：本文为Heriam博主原创文章，遵循CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接： https://jiang-hao.com/articles/2019/backend-transactions-acid.html 事务简介 事物的定义 事务（Transaction）是由一系列对系统中数据进行访问或更新的操作所组成的一个程序执行逻辑单元（Unit）。在计算机术语中，事务通常就是指 数据库 事务 。 在数据库管理系统（DBMS）中，事务是数据库恢复和并发控制的基本单位。它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。 例如，银行转帐工作：从源帐号扣款并使目标帐号增款，这两个操作必须要么全部执行，要么都不执行，否则就会出现该笔金额平白消失或出现的情况。所以，应该把他们看成一个事务。 在现代数据库中，事务还可以实现其他一些事情，例如，确保你不能访问别人写了一半的数据；但是基本思想是相同的——事务是用来确保 无论发生什么情况，你使用的数据都将处于一个合理的状态 ： transactions

分布式–BASE原则 概念 BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。 BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。 基本可用（Basically Available） 什么是基本可用呢？指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。**假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言： 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。 软状态 什么是软状态呢？ 相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。 软状态指的是： 指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在延时。 最终一致性 上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后

兴起原因 Not only SQL 传统的关系性数据库 关系代数理论基础 RDBMS只能纵向扩展：通过一台服务器增加性能终究难以满足数据量增长。 严格的数据库模式 索引机制，查询优化引擎：适当量级查询效率高 事务一致性：ACID 数据完整性：主键、约束 标准化：sql标准 技术支持：商业数据库 可维护：管理员维护 关系型数据库主从模式 面对日益增长的数据量，多台服务器的写主读从，分离单台服务器压力，但效果有限，且： 集群部署配置复杂 主库压力带来延迟 扩容重新分区复杂 web2.0的需求 关系型数据库事务机制需要额外的开销，但是在Web2.0通常不要求严格的数据库事务 不需要严格的读写实时性 不包含复杂的sql查询：连接操作牺牲性能节约空间 扩充关系型数据库无法实现的特点 1.灵活的可扩展性 2.灵活的数据模型 3.与云计算紧密结合：根据负载动态伸缩集群节点 NoSQL数据库优势 1.海量数据管理需求 2.高并发需求：动态数据实时生成性能需求 3.可扩展、高可用：突发事务访问量急剧增大 NoSQL数据库劣势 缺乏底层理论基础 事务强一致性：不适用关键业务 数据模型 不同场景下需要不同的数据模型 四大类型 键值数据库 如Redis存储键值对， 适合内容缓存 简单的数据模型 频繁读写 非结构化信息同时也有一些缺点，在一些场景下是不适合的：条件查询效率低、键与键之间没有办法反应联系关系

CAP原则 分布式–CAP原则 CAP理论是指分布式系统架构中通常只能够满足CAP三个指标中的两个，而不能同时满足CAP三个指标。 C（Consistency）：一致性 一致性指的是All nodes see the same data at the same time，也就是说所有节点在同一时间看到的数据必须是一模一样的 ，比如足球比赛中，当比分发生了改变，客户端A看到的比分是1:0，而客户端B看到的比分还是0:0；又比如在银行系统中，通过微信进行银行卡转账，卡上余额从100变成了0，但是在支付宝中查看银行卡余额还是100，这显然就破坏了数据的一致性。 A（Avalilability）：可用性 可用性指的是Reads and writes always succeed，也就是说无论是读操作还是写操作，始终是成功的，也就是服务一直可用，不存在服务失败或者用户操作失败的情况 。比如说用户发起提现操作，过了会显示提现失败；在进行转账的时候提示了需要等2天后才能到账，显然就破坏了可用性，因为用户的一系列操作换来的是提现失败，转账延迟才能到账，而不是立马响应到账。 P（ Partition Toleranc）：分区容错性 分区容错性指all nodes look like one node，也就是说多个节点的运行看起来就像是一个节点在运行一样，一个节点宕机不可用，其他节点还可以正常运行

1、zookeeper一致性原理 一致性概念：强一致性、弱一致性、最终一致性 为了保证主从节点的数据一致性，Zookeeper 采用了 ZAB 协议 ，这种协议非常类似于一致性算法 Paxos 和 Raft 什么是 ZAB Zookeeper Atomic Broadcast，有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。 # ZAB 协议定义的三种节点状态 Looking ：选举状态。 Following ：Follower 节点（从节点）所处的状态。 Leading ：Leader 节点（主节点）所处状态。 # 最大 ZXID 最大 ZXID 也就是节点本地的最新事务编号，包含 epoch 和计数两部分。epoch 是纪元的意思，相当于 Raft 算法选主时候的 term。 # ZAB 的崩溃恢复 假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段： Leader election 选举阶段，此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器 ID 和最新事务 ID（ZXID）。 接下来，节点会用自身的 ZXID 和从其他节点接收到的 ZXID 做比较，如果发现别人家的 ZXID 比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID