MVCC， ACID,BASIC 和Pasox的示例分析

这期内容当中小编将会给大家带来有关MVCC， ACID,BASIC 和Pasox的示例分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

MVCC是Multi-Version Concurrency Control 的缩写，中文是多版本并发控制

简单来说，MVCC的目的就是可以让在不同的事物中任意修改镜像，并通过比较版本号的形式来决定最新成功的事物。

但在现实中并不存在这样的乐观情况，比如说事物1修改了row1，事物2 修改了row1，事物1修改ROW2失败。那么将回滚row1.但由于事物2已经修改过row1，所以回滚的话，将导致事物2失效。所以纯粹的MVCC的架构并不适用于在数据库中的设计。

通常来说在数据库中的MVCC经常表现为，查询在同一个事物内，可以看到数据的是一致的，如果在事物进行中，数据被另外的事物修改，则去读取该数据的前镜像数据，不会因为其他人的修改而有所改变。

修改的过程依然是排他。而并非MVCC的乐观锁定。

ACID中的I的实现方法。

当事物进行修改数据时，在数据行中有隐藏的列，分别是ID,事物ID以及回滚前镜像ID，以及。在行数据被修改的时候，原数据会被copy到回滚段中，当前行的回滚前镜像ID，设置为回滚段中的ID。

MYSQL 只会查找数据版本号早于当前事物版本号的数据。所以当一个事物开始时，有被修改的数据，则会通过向前翻看回滚日志找到该数据的未修改改前的数值。

2PC

2PC 一般会有一个协调者进行操作，首先协调者会对自己进行写日志。然后给所有参与者发送prepare消息，询问包括自己在内的全部人是否可以commit本次transaction，参与者会先对事物进行预处理，如果可以提交，则会在自己身上写入日志，并会发给协调者 ready信息，并且自身进入可提交状态，如果不可提交则发送一个not commit的状态，同时撤销更改。

协调者如果收到not commit,则会记入日志并发送abort 信号。所有参与者撤销数据库更改。

协调者如果收到全部参与者的ready消息，则会将commit写入日志，并向所有参与者发送commit消息。如果收到所有的参与者消息，则会将食物提交 计入日志。

如果协调者迟迟未收到某些参与者的消息，则会认为该参与者发送了vote_abort的信号，从而对其他参与者发送ABORT信号。

在MySQL中其实有2种事物参与者，binlog ,redo log. 当事物发起时，binlog先发送prepare，其实什么都不会做，然后innodb引擎发送prepare,将事物的状态设置为TRX_PREPARED，开始刷新redo log到磁盘中。当所有存储引擎的prepare都成功，则将SQL语句写入到binlog.如果事物回滚，则不会写入bin log.最后调用存储引擎的commit完成事物的提交，binlog_commit什么都不会做因为binlog已经写完了。Innodb commit 则会进行刷redo log,清空undo的信息，将当前事物设置为TRX_NOT_STARTED状态

CAP

CAP 是指在分布式环境中的一致性，可用性和分区容灾性，而强行保留三项中的全部项会导致任意一项中的其他的两项无法证明。

业内通常的做法是牺牲一致性，但是即使牺牲了一致性也不一定可以保证可用性及分区容灾性，因为还有延迟的存在。

下面这一条总结的很好：

CAP 理论说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。注意，这里边最重要和最容易被人忽视的是限定词“对某个数据不存在一个算法”。这就是说在一个系统中，可以对某些数据做到 CP, 对另一些数据做到 AP，就算是对同一个数据，调用者可以指定不同的算法，某些算法可以做到 CP，某些算法可以做到 AP。

BASE：

BASE是Basically availability ,soft state, eventually consistent三个短语的缩写。

基于CAP理论，但核心思想是基于一致性与可用性进行权衡的结果，根据需求不同来设定不同的计划，如火车票系统与网购商品对一致性和可用性的要求就几乎相反。所以即使在无法做到强一致性的前提下，但应用可以根据自身特点采用适当的方式来是系统达到最终一致性。

1.Basically availability:

为了保障基本可用性，可以损失一部分性能，如搜索引擎出现故障时，可以从0.023秒的响应时间增加到2秒，虽然慢了 但不会404.当进行网站商品促销时，如果流量过大，为了保障功能可以用，消费者可能会被引导到一个降级页面。

2.soft state

指允许系统中数据存在中间状态，并认为中间状态的存在不会影响系统的整体可用性，这一点与CAP中的C概念完全相悖。即系统的数据在同步过程中允许存在延迟

3.eventually consistent

最终一致性的意思是在一段时间后，整个系统的数据全部副本会成为一致的状态，而不需要保证数据实时一致。

Base理论的是针对大型分布式系统的理论，数据无需保持实时一致，这与ACID中的强一致要求是不一致的，但ACID特性和BASE设计往往会参合在一起使用。

PASOX

Pasox分为basic和multi pasox.

Basic paxso主要是设计来如何解决在分布式环境下的唯一值问题。

在分布式环境中一般会多个proposer 和多个acceptor 。

每个proposer发起的提议会以（ID,VALUE）来进行标识。

每个acceptor可以接受多个提议，当多数的acceptor接受一项提议的时候，该提议被chosen。

在解决唯一值问题时其中有几个基本原则：

1.P1原则，acceptor 接受他收到的第一个提议

2.P2原则如果一个值V被接受，那么后续只确定值为V的提议。

3.P2a原则，如果一项值为V被chosen，那么acceptor后续只接受值为V的提议。

4.P2b原则，如果一项值为V的提议被chosen,那么后续proposer值发起值为V的提议

5.P2c原则，对于提议(n,v)，acceptor的多数派中，如果存在acceptor最近一次(ID最大）接受的提议值为V'，那么要求V=V’，否则V可以为任意值。

假设有A~E 5个acceptor，- 表示acceptor因宕机等原因缺席当次决议，x 表示acceptor不接受提议，o 表示接受提议；多数派acceptor接受提议后提议被确定，以上表格对应的决议过程如下：

第一轮，提议2为最先发起的提议，他可以发起任何值a.

第二轮，acceptor ABCE, ID是5的提议因为没有任何值被接受，所以可以是任何值b.（D缺席）

第三轮 ，acceptor BDE因为D接受了值a，所以ID为14的提议根据P2原则，则必须提议值a.

第四轮，acceptor ACD 因为C接受了值b ,A,D 接受了值a ,根据P2c原则，值b的提议ID大于值a 所以ID27的提议必须为b.

第五轮, acceptor BCD，BCD,都接受过了提议，相比之下CD曾接受的27号提议ID最大，所以29轮的提议必须为b.

为了实现p2c ，acceptor需要保证1，记录曾经接受的最大的提议ID号以便proposer查询以决定其提议值。2.在回应ID n之后，需要保证不再接受ID小于n的提议。

上述就是小编为大家分享的MVCC， ACID,BASIC 和Pasox的示例分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。