分布式一致性

这个怎么说呢？？？网上说的天花乱坠，说什么的都有，很早以前我感觉我理解了，现在回过头完全不知.... 首先我先描述下CAP，然后再详细解释。 1、可用性，也就是所谓的A（Consistency） 是指系统中任何一个节点宕机，其他节点也可以继续对外正常（此处待议）提供服务。 2、一致性，也就是所谓的C（Availability） 这个是比较好理解的，是指数据在任何时候，读取数据都是一致的，此处一致性指的是强一致性。 3、分区容忍性，也就是所谓的P（Partition tolerance） 这个是比较抽象点，分区容忍性强调是指系统中的节点因网络原因中断连接，导致出现分区现象，可以理解原本是整体，节点之间相互交互。出现这个现象和可用性不同地方在于，都可对外提供服务，但因出现分区，如果数据分区存储，就会出现对外提供数据异常。 争议问题 可用性： 什么算可用？什么算不可用？我程序出现异常，返回一个程序异常提示，算可用？如果算，那这个可用性就好处理了，处理不了我就都返回，那我就可以说我的程序是可用的？？？还是说可用指的是可以正常的业务场景处理，A、B两节点，A节点宕掉，B节点可以继续处理请求。所以，理解不同导致网上说法也大不一样。 一致性： 一致性是指强一致性，虽然时间差距在毫秒也不可否认有差距。大部分主从结构都是这样的，写入主节点后，会有线程会将数据写一份给从库

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

历史优质文章： 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机（jvm）的问题看这篇就够了 Java NIO 概览 分布式系统设计理念 分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。 分布式系统的目标与要素 分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。 即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。 分布式系统设计两大思路：中心化和去中心化 1）中心化设计： 两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色： “领导” 和 “干活的” 角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。 中心化设计的问题 ： 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题

【背景】 随着单体应用的缺陷日益明显，越多越多的公司都从传统的单体应用模式向新型的分布式应用模式转变。 实际上，在分布式应用带来巨大优势的同时，也伴随着各种挑战。例如，系统容错、网络延迟和分布式事务等。 本篇博客开始，将会对分布式事务做一系列学习总结。从本篇博客，我们可以了解到什么是分布式事务，关于分布式事务的相关理论以及处理分布式事务的解决方案。 【本地事务】 在没有接触分布式应用前，我们接触到的事务一般都是本地事务，即在单个数据库并且限制在单个进程内的事务。本地事务不涉及多个数据源。 若我们的系统使用了spring，一般加上@Transition注解即可保证事务正常运行。但如果是分布式系统应用下，若操作涉及不同的数据库，这样本地事务就失效了，从而就涉及到了分布式事务。 【分布式事务】 1. 什么是分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. 分布式事务的产生原因 从原来的单体应用到分布式应用的转变，便意味着从以前的一个系统到多个服务共同组成一个系统的转变。 如一个电商系统，拆分为订单

近期公司项目基于微服务架构需要涉及到实现一套分布式事务。经过几天在网上查阅资料发现大部分文章只是讲解了具体的其中一个模型。因此在这里做一个总结+自己的一些感悟和看法。 1.CAP理论 CAP理论本身并不是一套和事务相关的理论，而是用来解释分布式系统的理论。但是用来分析分布式事物的边界非常适合。关于CAP理论，可以查看阮一峰大神的这篇文章： CAP定理的含义 CAP理论一个核心论证就是P(分区容错性)作为一个分布式系统是肯定包含的。因此实际实现只是在CP和AP之间做抉择。 CP：为了保证一致性和分区容错性，那么肯定会丧失一部分可用性。 AP：为了保证可用性和分区容错性，那么肯定会丧失一部分一致性。 2.ACID原则 ACID原则是用来描述一个事务应该包含的特性。原子性、一致性、隔离性、持久性。这个原则实际上和CAP理论是相悖的。 3.刚性事务、CP模式、XA协议 我们来假设一个简单的支付场景， 生成订单--->扣用户积分--->核销优惠劵--->修改订单状态 。这里涉及三个系统，订单系统、用户积分系统、优惠劵系统。那么如果我们要保证事务的一致性，我们在其中的每一步都会将资源锁定，然后只有在最终事务全部完成后，我们才能释放锁。那么在整个事务周期内我们的功能必定是处于不可用状态。这也正符合 CP定义 。这么做的事务确实可以保证事务的ACID原则，但是因为锁定时间长、锁粒度大(锁定资源多)

引言 狭义的分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。广义的分布式系统是一个相对的概念，正如Leslie Lamport所说[1]： What is a distributed systeme. Distribution is in the eye of the beholder. To the user sitting at the keyboard, his IBM personal computer is a nondistributed system. To a flea crawling around on the circuit board, or to the engineer who designed it, it’s very much a distributed system. 一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。 一致性(consensus) 何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)

转载自： https://blog.csdn.net/losetowin/article/details/53743135 适当做了一些修改,最后加了自己的一些理解 1、项目场景 (1) 单个节点的缓存容量达到上限，无法继续单点增加内存，如何解决？ (2) 单个节点 支撑的 QPS (每秒查询率)达到上限， 如何解决 ？ 2、 初步方案 增加 N 个 缓存节点 ，为了保证 缓存数据的均匀 ，一般情况会采用对 key值hash ，然后 取模 的方式，然后根据结果，确认数据落到哪台节点上：如下： hash(key)%N 很好，这个的确解决了上面的问题，实现了 初步的分布式缓存 ， 数据均匀分散 到了各个节点上， 流量请求也均匀的分散 到了各个节点。 (1) 但是如果出现以下情况，会带来什么问题？ 某台服务器 突然宕机 。缓存服务器从 N 变为 N-1 台。 缓存容量 达到 上限 或者 请求处理达到上限 ，需要 增加缓存服务器 ，假定增加1台，则缓存服务器从 N 变为 N+1 上面的情况带来的问题： 增加 或者 删除 缓存服务器的时候，意味着 大部分的缓存都会失效 。这个是 比较致命 的一点，缓存失效，如果 业务为缓存不命中 ，查询DB的话，会导致 一瞬间DB的压力陡增 。可能会 导致整个服务 不可用。 (2) 换种描述方式，我们需要解决怎么样的问题？或者需求是怎样的？ 增删 机器时，

https://www.cnblogs.com/bangerlee/p/5328888.html 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)：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败

Paxos协议/算法是分布式系统中比较重要的协议，它有多重要呢？ <分布式系统的事务处理> ： Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 <大规模分布式存储系统> ： 理解了这两个分布式协议之后(Paxos/2PC)，学习其他分布式协议会变得相当容易。 学习Paxos算法有两部分：a) 算法的原理/证明；b) 算法的理解/运作。 理解这个算法的运作过程其实基本就可以用于工程实践。而且理解这个过程相对来说也容易得多。 网上我觉得讲Paxos讲的好的属于这篇： paxos图解 及 Paxos算法详解 ，我这里就结合 wiki上的实例 进一步阐述。一些paxos基础通过这里提到的两篇文章，以及wiki上的内容基本可以理解。 算法内容 Paxos在原作者的《Paxos Made Simple》中内容是比较精简的： Phase 1 (a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors. (b) If an acceptor receives a prepare request with number n greater than

1.ACID特性 数据库管理系统中事务(transaction)的四个特性： 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 1、原子性 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么全部成功，要么全部失败。 2、一致性 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。 3、隔离性 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。 4、持久性 持久性，意味着在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。 2.CAP理论 CAP理论，指的是在一个分布式系统中，不可能同时满足Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能满足其中的两项。 1、一致性： 指数据在多个副本之间是否能够保持一致的特性。当执行数据更新操作后，仍然可以保证系统数据处于一致的状态。 2、可用性： 系统提供的服务必须一直处于可用的状态。对于用户的每一个操作请求总是能够在“有限的时间内”返回结果。这个有限时间是系统设计之初就指定好的系统运行指标