共计 3147 个字符，预计需要花费 8 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关 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 的提议。
上述就是丸趣 TV 小编为大家分享的 MVCC，ACID,BASIC 和 Pasox 的示例分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
