分布式数据库一致性

① 数据库的acid中的一致性到底是什么意思

数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果

常用的一致性模型有：
a、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

b、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的。
c、因果一致性（causal consistency）：只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中来的写操作则无需保证顺序，就像一个一个的管道一样。 相对来说比较容易实现。
e、弱一致性（weak consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性，是全局可见的，且只有当没有写操作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。
f、 释放一致性（release consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区， 释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了一个临界区，提供 释放一致性也就意味着当release操作发生后，所有使用者应该可以看到该操作。

② 分布式数据库有什么特点

1.数据独立性与位置透明性
数据独立性是数据库方法追求的主要目标之一，分布透明性指用户不必关心数据的逻辑分区，不必关心数据物理位置分布的细节，也不必关心重复副本（冗余数据）的一致性问题，同时也不必关心局部场地上数据库支持哪种数据模型。分布透明性的优点是很明显的。有了分布透明性，用户的应用程序书写起来就如同数据没有分布一样。当数据从一个场地移到另一个场地时不必改写应用程序。当增加某些数据的重复副本时也不必改写应用程序。数据分布的信息由系统存储在数据字典中。用户对非本地数据的访问请求由系统根据数据字典予以解释、转换、传送。

2.集中和节点自治相结合
在分布式数据库中，数据的共享有两个层次：一是局部共享，即在局部数据库中存储局部场地上各用户的共享数据．这些数据是本场地用户常用的。二是全局共享，即在分布式数据库的各个场地也存储可供网中其它场地的用户共享的数据，支持系统中的全局应用。因此，相应的控制结构也具有两个层次：集中和自治。分布式数据库系统常常采用集中和自治相结合的控制结构,各局部的DBMS可以独立地管理局部数据库，具有自治的功能。同时，系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用。另外，在不同的系统集中和自治的程度不尽相同。
3.支持全局数据库的一致性和和可恢复性
分布式数据库中各局部数据库即满足集中式数据库的一致性、可串行性和可恢复性，还保证了数据库的全局一致性、并行操作的可串行性和系统的全局可恢复性。这是因为全局应用要涉及两个以上结点的数据。因此在分布式数据库系统中一个业务可能由不同场地上的多个操作组成。这样，当其中某一个结点出现故障操作失败后如何使全局业务滚回呢？如何使另一个结点撤销已执行的操作(若操作已完成或完成一部分）或者不必再执行业务的其它操作(若操作尚没执行)？这些技术要比集中式数据库复杂和困难得多，分布式数据库系统必须解决这些问题。
4.复制透明性
用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。在分布式数据库系统中，可以把一个场地的数据复制到其他场地存放，应用程序可以使用复制到本地的数据在本地完成分布式操作，避免通过网络传输数据，提高了系统的运行和查询效率。但是对于复制数据的更新操作，就要涉及到对所有复制数据的更新。
5.易于扩展性
在大多数网络环境中，单个数据库服务器最终会不满足使用。如果服务器软件支持透明的水平扩展，那么就可以增加多个服务器来进一步分布数据和分担处理任务。

③ 分布式系统中，为什么要定义不同的一致性模型，其具有什么意义

1. 数据库定义:数据库是长期储存在计算机内、有组织的、可共享的大量数据的集合。数据库中的数据按一定的数据模型组织、描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。2. 数据库管理技术发展的三个阶段：人工管理阶段，文件系统阶段，数据库系统阶段。3. DBMS（数据库管理系统）是位于用户与操作系统之间的一层数据管理软件。主要功能：1，数据定义功能。2，数据组织、存储和管理。3，数据操纵功能。4，数据库的事务管理和运行管理。5，数据库的建立和维护功能。6，其他功能。4. 什么是数据模型及其要素? (设计题)： 数据模型是数据库中用来对现实世界进行抽象的工具，是数据库中用于提供信息表示和操作手段的形式构架。一般地讲，数据模型是严格定义的概念的集合。这些概 念精确地描述系统的静态特性、动态特性和完整性约束条件。因此数据模型通常由数据结构、数据操作和完整性约束三部分组成。 (1)数据结构：是所研究的对象类型的集合，是对系统的静态特性的描述。 (2)数据操作：是指对数据库中各种对象(型)的实例(值)允许进行的操作的集合，包括操作及有关的操作规则，是对系统动态特性的描述。 (3)数据的约束条件：是完整性规则的集合，完整性规则是给定的数据模型中数据及其联系所具有的制约和依存规则，用以限定符合数据模型的数据库状态以及状态的变化，以保证数据的正确、有效、相容。最常用的数据模型：层次模型，网状模型，关系模型，面积对象模型，对象关系模型。5.常用的数据模型有哪些（逻辑模型是主要的），各有什么特征，数据结构是什么样的。答：数据模型可分为两类：第一类是概念模型，也称信息模型，它是按用户的观点来地数据和信息建模，主要用于数据库设计。第二类是逻辑模型和物理模型。其中逻辑模型主要包括层次模型、层次模型、关系模型、面向对象模型和对象关系模型等。它是按计算机系统的观点对数据建模，主要用于DBMS的实现。物理模型是对数据最低层的抽象，它描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法，是面向计算机系统的。物理模型是具体实现是DBMS的任务，数据库设计人员要了解和选择物理醋，一般用户则不必考虑物理级的细节。层次数据模型的数据结构特点：一是：有且只有一个结点没有双亲结点，这个结点称为根结点。二是：根 以外的其他结点有且只有一个双亲结点。优点是：1.层次 数据结构比较简单清晰。2.层次数据库的查询效率高。3.层次数据模型提供了良好的完整性支持。缺点主要有：1.现实世界中很多联系是非层次性的，如结点之间具有多对多联系。2.一个结点具有多个双亲等 ，层次模型表示这类联系的方法很笨拙，只能通过引入冗余数据或创建非自然的数据结构来解决。对插入和删除操作的限制比较多，因此应用程序的编写比较复杂。3.查询子女结点必须通过双亲结点。4.由于结构严密，层次命令趋于程序化。可见用层次模型对具有一对多的层次联系的部门描述非常自然，直观容易理解，这是层次数据库的突出优点。网状模型：特点：1.允许一个以上的结点无双亲2.一个结点可以有多于一个的双亲。网状数据模型的优点主要有：1.能够更为直接地描述现实世界，如一个结点可以有多个双亲。结点 之间可以有多种上联第。2.具有良好的性能，存取效率较高。缺点主要有：1.结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终 用户掌握。2.网状模型的DDL,DML复杂,并且要嵌入某一种高级语言中，用户不容易掌握，不容易使用。关系数据模型具有下列优点：1.关系模型与非关系模型不同，它是建立在严格的数学概念的基础上的。2.关系模型的概念单一。。3.关系模型的存取路径对用户透明，从而具有更高的数据独立性，更好的安全保密性，也简化了程序员的工作和数据库开发的建立 的工作。。主要的缺点是：由于存取路径房租明，查询效率往往不如非关系数据模型。因此为了提高性能，DBMS必须对用户的查询请求进行优化。因此增加 了开发DBMS的难度，不过用户不必考虑这些系统内部的优化技术细节。6.三级体系结构，外模式，模式 ，内模式定义是什么？模式也称逻辑模式，是数据库中全体数据的逻辑结构和牲的描述，是所有用户的公共数据视图。 外模式也称子模式或用户模式，它是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图是与某一应用有关的数据的逻辑表示。 内模式也称存储模式 ，是一个数据库只有一个内模式。它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。7.两级映像和两级独立性，为什么叫物理独立性和逻辑独立性。当模式改变时由数据库管理员对各个外模式、模式的映像亻相应改变，可以使外模式保持不变。应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立生，简称数据的逻辑独立性。当数据库的存储结构改变了，由数据库管理员对模式、内模式映像作 相应改变，可以使模式保持不变，从而应用程序也不必改变。保证了数据与程序的物理独立性，简称数据的物理独立性。8.数据库系统一般由数据库、数据库管理系统 （及其开发工具）、应用系统和数据库管理员构成。9.关系的完整性（实体完整性、参照完整性、和用户定义的完整性）三部分内容，其中前二者是系统自动支持的，DBMS完整性控制子系统的三个主要功能？：提供定义完整性约束条件的机制，提供完整性检查的方法，违约处理。16.SQL的定义；即结构化查询语言，是关系数据库的标准语言，是一个通用的、功能极强的关系数据库语言。分类（交互式和嵌入式）17.group by 和having子句的作用20.视图的概念：视图是从一个或几个基本表导出的表。及相关操作：定义视图，查询视图，更新视图。视图更新有什么操作：插入，删除，和修改。22.数据库规范化的方法函数依赖的定义什么叫1NF2NF3NF BCNF定义：关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。各种范式之间的联系有：5NF（4NF（BCNF（3NF（2NF（1NF。25.数据库设计的几个阶段，每个阶段常用的方法和简要的内容：六个阶段：需求分析、概念结构设计、罗织结构设计、物理设计、数据库实施、数据库运行和维护。28.事务的概念？事务有哪些基本属性commit roll back含义：事务：是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的单位。四个特性：原子性，一致性，隔离性，持续性。Commit（提交：提交事务的所有操作） rollback（回滚：在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。 29.什么叫数据库系统的可恢复性？：数据库管理系统具有把数据库从错误状态恢复到某一已知的正确状态的功能，这就是数据库系统的可恢复性。数据库故障的种类：事务内部的故障，系统故障（软故障），介质故障（硬故障），计算机病毒。30.不进行并发控制可能产生的问题？：多个事务对数据库并发操作可能造成事务ACID特点遭到在破坏。如何解决（三个）：1，丢失修改 2，不可重复读 3，读“脏”数据。31.三级封锁协议？能解决什么问题？：一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。一级封锁协议中，如果是读数据不修改，是不需要加锁的，可防止丢失修改。二级封锁协议：在一级封锁协议基础上，加上事务T在读数据R之前必须先对其加上S锁，读完后即可释放S锁。在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。三级封锁协议：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。三级封锁协议除了防止了丢失修改和不读“脏”数据外，还进一步防止了不可重复读。上述三级协议的主要区别在于：什么操作需要申请封锁，以及何时释放锁。一般采取哪三种措施？插入呢？删除呢？：1，拒绝执行（不允许该操作执行），2，级连操作（当删除或修改被参照表的一个元组造成了与参照表的不一致，则删除或修改参照表中的所有造成不一致的元组），3，设置为空值（当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有不造成不一致的元组的对应属性设置为空值）。38.视图对数据库安全性的作用？：1，视图能够简化用户的操作，2，视力使用户能以多种角度看待同一数据，3，视图对重构数据库提供了一定程度的逻辑独立性，4，视图能够对机密数据提供安全保护，5，适当的利用视图可以更清晰的表达查询。数据库：储存在计算机内，永久存储、有组织、有共享的大量数据的集合。数据管理技术的发展阶段：1.人工管理阶段：数据不保存，应用程序管理数据，数据不共享，数据不具有独立性。2.文件系统阶段：数据可以长期保存，由文件系统管理数据；数据共享性太差，冗余度大，数据独立性差。3.数据库系统阶段：出现数据库管理系统。数据库系统的特点：数据结构化（本质区别）；数据共享性高、冗余度低、易扩充；数据独立性高；数据有DBMS统一管理和控制。数据库管理系统：1.定义：DBMS，是位于用户与操作系统之间的一层数据管理软件。2.功能：数据定义功能；数据组织、存储和管理；数据操纵功能；数据库的事务管理和运行管理；数据库的建立和维护功能；通信功能、数据转换功能、互访和互操作功能。数据库系统：1.概念：DBS，是指在计算机系统中引入数据库后的系统。2.组成：一般由数据库、数据库管理系统、应用系统、数据库管理员构成。3.分类：集中式，C/S式，并行式，分布式。数据模型：1.定义：现实世界数据特征的抽象。2.组成，三要素：数据结构、数据操作、数据的完整性约束。两类数据模型为1）概念模型2）逻辑模型和物理模型。数据结构：描述数据库的组成对象以及对象之间的联系，主要描述与对象的类型、内容、性质有关的对象和与数据之间联系有关的对象。常用的数据模型：1.层次模型，用树形结构表示各类实体以及实体间的联系。2.网状模型，允许一个以上的结点无双亲，允许一个结点可以有多于一个的双亲。3.关系模型，包含单一数据结构

④ 分布式存储中，怎样使用paxos算法保证数据的一致性

在分布式系统中，我们经常遇到多数据副本保持一致的问题，在我们所能找到的资料中该问题讲的很笼统，模模糊糊的，把多个问题或分类糅合在一起，难以理解。在思考和翻阅资料后，通俗地把一致性的问题可分解为2个问题：
1、任何一次修改保证数据一致性。
2、多次数据修改的一致性。
在弱一致性的算法，不要求每次修改的内容在修改后多副本的内容是一致的，对问题1的解决比较宽松，更多解决问题2，该类算法追求每次修改的高度并发性，减少多副本之间修改的关联性，以获得更好的并发性能。例如最终一致性，无所谓每次用户修改后的多副本的一致性及格过，只要求在单调的时间方向上，数据最终保持一致，如此获得了修改极大的并发性能。
在强一致性的算法中，强调单次修改后结果的一致，需要保证了对问题1和问题2要求的实现，牺牲了并发性能。本文是讨论对解决问题1实现算法，这些算法往往在强一致性要求的应用中使用。
解决问题1的方法，通常有两阶段提交算法、采用分布式锁服务和采用乐观锁原理实现的同步方式,下面分别介绍这几种算法的实现原理。

两阶段提交算法

在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。两阶段提交协议由两个阶段组成，在正常的执行下，这两个阶段的执行过程如下所述：
阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）。
在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
阶段2：提交阶段（commit phase）。
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
举个例子：A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用2PC算法解决该问题的过程如下：
首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。
阶段1：A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因，D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
阶段2：此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。
两阶段提交算法在分布式系统结合，可实现单用户对文件（对象）多个副本的修改，多副本数据的同步。其结合的原理如下：
1、客户端（协调者）向所有的数据副本的存储主机（参与者）发送：修改具体的文件名、偏移量、数据和长度信息，请求修改数据，该消息是1阶段的请求消息。
2、存储主机接收到请求后，备份修改前的数据以备回滚，修改文件数据后，向客户端回应修改成功的消息。 如果存储主机由于某些原因（磁盘损坏、空间不足等）不能修改数据，回应修改失败的消息。
3、客户端接收发送出去的每一个消息回应，如果存储主机全部回应都修改成功，向每存储主机发送确认修改的提交消息；如果存在存储主机回应修改失败，或者超时未回应，客户端向所有存储主机发送取消修改的提交消息。该消息是2阶段的提交消息。
4、存储主机接收到客户端的提交消息，如果是确认修改，则直接回应该提交OK消息；如果是取消修改，则将修改数据还原为修改前，然后回应取消修改OK的消息。
5、 客户端接收全部存储主机的回应，整个操作成功。
在该过程中可能存在通信失败，例如网络中断、主机宕机等诸多的原因，对于未在算法中定义的其它异常，都认为是提交失败，都需要回滚，这是该算法基于确定的通信回复实现的，在参与者的确定回复（无论是回复失败还是回复成功）之上执行逻辑处理，符合确定性的条件当然能够获得确定性的结果哲学原理。

分布式锁服务

分布式锁是对数据被外界修改持保守态度，在整个数据处理过程中将数据处于锁定状态，在用户修改数据的同时，其它用户不允许修改。
采用分布式锁服务实现数据一致性，是在操作目标之前先获取操作许可，然后再执行操作，如果其他用户同时尝试操作该目标将被阻止，直到前一个用户释放许可后，其他用户才能够操作目标。分析这个过程，如果只有一个用户操作目标，没有多个用户并发冲突，也申请了操作许可，造成了由于申请操作许可所带来的资源使用消耗，浪费网络通信和增加了延时。
采用分布式锁实现多副本内容修改的一致性问题， 选择控制内容颗粒度实现申请锁服务。例如我们要保证一个文件的多个副本修改一致， 可以对整个文件修改设置一把锁，修改时申请锁，修改这个文件的多个副本，确保多个副本修改的一致，修改完成后释放锁；也可以对文件分段，或者是文件中的单个字节设置锁， 实现更细颗粒度的锁操作，减少冲突。
常用的锁实现算法有Lamport bakery algorithm （俗称面包店算法）， 还有Paxos算法。下面对其原理做简单概述。

Lamport面包店算法

是解决多个线程并发访问一个共享的单用户资源的互斥问题的算法。 由Leslie Lamport（英语：Leslie Lamport）发明。
Lamport把这个并发控制算法可以非常直观地类比为顾客去面包店采购。面包店只能接待一位顾客的采购。已知有n位顾客要进入面包店采购，安排他们按照次序在前台登记一个签到号码。该签到号码逐次加1。根据签到号码的由小到大的顺序依次入店购货。完成购买的顾客在前台把其签到号码归0. 如果完成购买的顾客要再次进店购买，就必须重新排队。
这个类比中的顾客就相当于线程，而入店购货就是进入临界区独占访问该共享资源。由于计算机实现的特点，存在两个线程获得相同的签到号码的情况，这是因为两个线程几乎同时申请排队的签到号码，读取已经发出去的签到号码情况，这两个线程读到的数据是完全一样的，然后各自在读到的数据上找到最大值，再加1作为自己的排队签到号码。为此，该算法规定如果两个线程的排队签到号码相等，则线程id号较小的具有优先权。
把该算法原理与分布式系统相结合，即可实现分步锁。

Paxos算法

该算法比较热门，参见WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。节点通信存在两种模型：共享内存(Shared memory)和消息传递(Messages passing)。Paxos算法就是一种基于消息传递模型的一致性算法。BigTable使用一个分布式数据锁服务Chubby，而Chubby使用Paxos算法来保证备份的一致性。

采用乐观锁原理实现的同步

我们举个例子说明该算法的实现原理。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用前面的分布式锁服务机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
操作员 A 此时将其读出（version=1 ），并从其帐户余额中扣除 $50（$100-$50 ）。
在操作员 A 操作的过程中，操作员B也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
乐观锁机制与分布式系统相结合上， 我整理了伪代码如下：
obj 操作的目标
vlaue 修改的值
atom_update_ver 每个目标上的版本，每次修改该值递增
set( obj, value)
{
//从每个节点上取出修改前的对象版本
get original_ver = obj.atom_update_ver from each node;
//将值赋到每个节点的obj目标
set obj = value from each node;
//条件修改每个节点的obj版本，目标版本加一
//比较和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功递归修改

该算法未考虑节点下线、失效等问题，在后续我将分析采用乐观锁原理实现一致性算法，解决问题2、节点失效、通信失败等问题。

⑤ 分布式系统常用的一致性算法有哪些

有一些系统设计基础的话，给你推荐几本书吧： 《面向模式的软件架构 卷4：分布式计算的模式语言》出版社：人民邮电出版社 主要讲分布式计算系统软件的设计和实现。 偏软件方向，相对较专业。 《分布式计算（第二版）》出版社：电子工业出版社 主要介绍分布式计算的数学基础和理论，揭示设计分布式系统的底层问题（通信、协调、同步及不确定）和基本的算法概念及下界技术。 容易理解，适合自学。 《分布式系统原理与范型》出版社：清华大学出版社 全书的第一部分讨论了分布式系统的原理、概念和技术，其中包括通信、进程、命名、同步、一致性和复制、容错以及安全。第二部分给出了一些实际的分布式系统：基于对象的分布式系统、分布式文件系统、基于文档的分布式系统以及基于协作的分布式系统，介绍了一些实际系统的设计思想和实现技术。 容易理解，适合自学。

⑥ 有哪些分布式数据库，实现最终一致性的

可以关注下国产分布式数据库 TiDB，由于实现原理的原因，tidb 天生数据强一致性。TiDB 社区（AskTUG）

• 分布式事务

  TiDB 100% 支持标准的 ACID 事务。

• 真正金融级高可用

  相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

⑦ 数据库系统中 数据的一致性指的是什么

同步更新。

简单说来就是一条column的数据在多个表中保持同步更新， 一般用foreign key实现mapping

比如两张表table1,table2

其中table1的uid column是primary key，table2的uid column是foreign key,

则当修改table1的uid column的一row时，table2的对应row也会自动更新。

(7)分布式数据库一致性扩展阅读：

常用的一致性模型有：

1、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

2、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的，等。

⑧ 什么是NoSQL数据库

2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。

⑨ 什么是分布式环境中数据的强一致性

一致性又可以分为强一致性与弱一致性。 强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。 弱一致性包含很多种不同的实现，目前分布式系统中广泛实现

⑩ 如何解决分布式系统数据事务一致性问题

用户在京东上下了一个订单，发现自己在京东的账户里面有余额，然后使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。假设订单系统，支付系统，仓库系统是三个独立的应用，是独立部署的，系统之间通过远程服务调用。 订单的有三个状态：I:初始 P:已支付 W:已出库，订单金额100, 会员帐户余额200 如果整个流程比较顺利，正常情况下，订单的状态会变为I->P->W，会员帐户余额100，订单出库。 但是如果流程不顺利了？考虑以下几种情况 1：订单系统调用支付系统支付订单，支付成功，但是返回给订单系统数据超时，订单还是I（初始状态），但是此时会员帐户余额100,会员肯定会马上找京东骂京东，为啥不给老子发货，我都付钱了 2：订单系统调用支付系统成功，状态也已经更新成功，但是通知仓库发货失败，这个时候订单是P（已支付）状态，此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。 3：订单系统调用支付系统成功，状态也已经更新成功，然后通知仓库发货，仓库告诉订单系统，没有货了。这个时候数据状态和第二种情况一样。 对于问题一，我们来分析一下解决方案，能想到的解决方案如下 1 假设调用支付系统支付订单的时候先不扣钱，订单状态更新完成之后，在通知支付系统你扣钱 如果采用这种设计方案，那么在同一时刻，这个用户，又支付了另外一笔订单，订单价格200，顺利完成了整个订单支付流程，由于当前订单的状态已经变成了支付成功，但是实际用户已经没有钱支付了，这笔订单的状态就不一致了。即使用户在同一个时刻没有进行另外的订单支付行为，通知支付系统扣钱这个动作也有可能完不成，因为也有可能失败，反而增加了系统的复杂性。 2 订单系统自动发起重试，多重试几次，例如三次，直到扣款成功为止。 这个看起来也是不错的考虑，但是和解决方案一样，解决不了问题，还会带来新的问题，假设订单系统第一次调用支付系统成功，但是没有办法收到应答，订单系统又发起调用，完了，重复支付，一次订单支付了200。 假设支付系统正在发布，你重试多少次都一样，都会失败。这个时候用户在等待，你怎么处理？ 3 在第二种方案的基础上，我们先解决订单的重复支付行为，我们需要在支付系统上对订单号进行控制，一笔订单如果已经支付成功，不能在进行支付。返回重复支付标识。那么订单系统根据返回的标识，更新订单状态。 接下来解决重试问题，我们假设应用上重试三次，如果三次都失败，先返回给用户提示支付结果未知。假设这个时候用户重新发起支付，订单系统调用支付系统，发现订单已经支付，那么继续下面的流程。如果会员没有发起支付，系统定时（一分钟一次）去核对订单状态，如果发现已经被支付，则继续后续的流程。 这种方案，用户体验非常差，告诉用户支付结果未知，用户一定会骂你，你丫咋回事情，我明明支付了，你告诉我未知。假设告诉用户支付失败，万一实际是成功的咋办。你告诉用户支付成功，万一支付失败咋办。 4 第三种方案能够解决订单和支付数据的一致性问题，但是用户体验非常差。当然这种情况比较可能是少数，可以牺牲这一部分的用户体验，我们还有没有更好的解决方案，既能照顾用户体验，又能够保证资金的安全性。 我们再回来看看第一种方案，我们先不扣钱，但是有木有办法让这一部分钱不让用户使用，对了，我们先把这一部分钱冻结起来，订单系统先调用支付系统成功的时候，支付系统先不扣钱，而是先把钱冻结起来，不让用户给其他订单支付，然后等订单系统把订单状态更新为支付成功的时候，再通知支付系统，你扣钱吧，这个时候支付系统扣钱，完成后续的操作。 看起来这个方案不错，我们仔细在分析一下流程，这个方案还存在什么问题，假设订单系统在调用支付系统冻结的时候，支付系统冻结成功，但是订单系统超时，这个时候返回给用户，告知用户支付失败，如果用户再次支付这笔订单，那么由于支付系统进行控制，告诉订单系统冻结成功，订单系统更新状态，然后通知支付系统，扣钱吧。如果这个时候通知失败，木有问题，反正钱都已经是冻结的了，用户不能用，我只要定时扫描订单和支付状态，进行扣钱而已。 那么如果变态的用户重新拍下来一笔订单,100块钱，对新的订单进行支付，这个时候由于先前那一笔订单的钱被冻结了，这个时候用户余额剩余100，冻结100，发现可用的余额足够，那就直接在对用户扣钱。这个时候余额剩余0，冻结100。先前那一笔怎么办，一个办法就是定时扫描，发现订单状态是初始的话，就对用户的支付余额进行解冻处理。这个时候用户的余额变成100，订单数据和支付数据又一致了。假设原先用户余额只有100，被冻结了，用户重新下单，支付的时候就失败了啊，的确会发生这一种情况，所以要尽可能的保证在第一次订单结果不明确的情况，尽早解冻用户余额，比如10秒之内。但是不管如何快速，总有数据不一致的时刻，这个是没有办法避免的。 第二种情况和第三种情况如何处理，下次在分析吧。 由于互联网目前越来越强调分布式架构，如果是交易类系统，面临的将会是分布式事务上的挑战。当然目前有很多开源的分布式事务产品，例如java JPA，但是这种解决方案的成本是非常高的，而且实现起来非常复杂，效率也比较低下。对于极端的情况：例如发布，故障的时候都是没有办法保证强一致性的。