mysql小白系列_01 原理

1.什么是MVCC？有什么作用？

Multi-Version Concurrency Conrol 多版本并发控
为解决数据库并发读写可能会出现不一致数据的情况，需要实现数据库的并发访问控制，写时复制产生数据副本。

2.ACID中的I是怎么实现在的？

Isolation隔离性

• 读未提交 A事务更改了某个数据但并未提交，B事务可以访问这个数据的旧值。
• 读已提交 A事务更改了某个数据并提交，B事务只能读到更改后的数据。
• 可重复读 A事务更改某个数据前，B事务能读到这个数据，A更改这个数据后，B事务能读到这个数据的新值
• 串行化 A事务操作完了，B事务才能操作。

3.2PC在数据库中是怎么来实现的？

请求、提交两阶段
要么所有参与者同意，进行事务操作，如果有任何一个参与者不同意事务操作，则进行事务取消，保证所有数据副本都是一致的。
优点：原理简单、实现方便 缺点：二阶段会产生阻塞、协调者存在单点、参与者可能收不到协调者的commit请求，造成数据不一致
3PC解决了2PC的阻塞问题，但是数据不一致依然存在

4. 简单讲讲CAP/base/paxos算法

CAP

三选二，P分区可扩展性不能放弃，组合通常是PC或者PA

BASE

CAP的扩展，允许一段时间内的数据不一致来获得系统可用性，并最终数据达成一致性

PAXOS

• follower
• candidate
• leader

1. 初始阶段所有节点都是follower，当folower监听听不到leader，将自己置为candidate，发起投票选举leader
2. follower成为candidate的超时时间，每个follower都有随机超时时间，谁先timeout，谁先成为candidate，并给自己投一票，再向其他节点发起投片邀请
3. 如果其他节点在这轮选举还没有投过票，那么就给candidate投票，然后重置自己的选举timeout
4. 如果首先超时的candidate得到大多数的投票，将成为leader，之后定时向follower发送心跳
5. 如果两个follower同时成为candidate，并得到相同票数，则其他follower选择timeout后成为candidate，继续开始从新一轮选举leader

https://segmentfault.com/a/1190000004474543

---

ACID

事务的四个特征

1.Atomic原子性

事务必须是一个原子的操作序列单元，事务中包含的各项操作在一次执行过程中，要么全部执行成功，要么全部不执行，任何一项失败，整个事务都需要回滚，只有全部都执行成功，整个事务才算成功。
原子不可分，要么成功提交，要么失败回滚

2.Consistency一致性

事务的执行不能破坏数据库数据的完整性和一致性，事务在执行之前和之后，数据库都必须处于一致性状态。
oracle数据库（SCN）在不一致状态下，是无法open的

3.Isolation隔离性

在并发环境中，并发事务是相互隔离的，一个事务的执行不能被其他事务干扰。即不通的事务并发操纵相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰。
我写我的读我的，不会被你所写所读所干扰

SQL中4个事务隔离级别

• 读未提交

允许脏读。A事务更改了某个数据但并未提交，B事务可以访问这个数据的旧。

• 读已提交

允许不可重复读。只允许读到已经提交的数据。A事务累加n从0到10，B事务只能读到结果10，中间值无法读取，同时C事务将n累加到20，B事务再次读取，读到结果20

• 可重复读

 - 允许幻读。保证在事务处理过程中，多次读取同一个数据时，其值都和事务开始时刻时是一致的。
 - 禁止脏读、不可重复读。
 - 幻读，同一个事务不同的时间段内读取n，值可能是0,10,20
 - 幻读，就是不同事务，读到的n可能是0，可能是10，可能是20，

• 串行化

所有事务顺序执行，不能并发。

看到要么是提交前的数据，要么是提交后的数据

不控制并发的情形

• 一类丢失更新：两事务读取同一数据，A修改字段1，B修改字段2，后提交的恢复先提交修改的字段，造成其中之一更新丢失。
• 二类丢失更新：两事务读取同一数据，后提交的覆盖先提交的修改。
• 脏读：读到未提交的值，万一事务回滚，产生脏读。
• 不可重复读：两个查询之间，被另外一个事务修改了数据的内容，产生内容不一致，所见不是实际数据。
• 幻读：两个查询之间，被另外的事务插入或者删除了记录，产生结果集不一致。

4.Durability持久性

一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的，即使发生系统崩溃或机器宕机，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态。
提交的事务只要数据库能打开，数据就存在，没提交的回滚丢失

---

什么事MVCC？有什么作用

Multi-Version Concurrency Conrol 多版本并发控制

• 解决问题：
  • 控制并发操作并降低系统开销
  • 锁机制也可以控制并发，但开销稍大。
• MVCC实现：基于时间点保存数据的快照来实现，不用存储引擎的MVCC实现机制也不一样，典型的有：
  • 乐观并发控制
  • 悲观并发控制

innodb的MVCC

• 每行记录后面保存两个隐藏的列
• 分别是行创建时间、行删除时间
• 保存的是系统版本号（类似事务ID），并不是实际时间值
• 每开始一个新的事务，系统版本号自增
• 事务开始时刻的系统版本号会作为事务的ID

http://blog.csdn.net/whoamiyang/article/details/51901888
http://blog.sina.com.cn/s/blog_711b11fd0101bhks.html 怎么查看着两个隐藏列的？

2PC在数据库中是怎么来实现的？

• 分布式一致性 分布式系统中，为保证数据高可用，将数据的多个副本放置到不同的物理机上，用户的增删改查对所有的数据副本都需要保证是一致的。 解决分布式一致性问题的算法：
• 2PC Two Phase Commit Protocol 二阶段提交协议
• 3PC Three Phase Commit Protocol 三阶段提交协议
• Paxos

2PC

角色：

• 协调者（coordinator) 通常只有一个
• 事务参与者（participants、cohorts、workers），通常有多个，数据存储系统这是副本个数

两个阶段：

• 请求阶段（commit-request phase、表决阶段、votingphase，选举阶段）
  • 协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。
  • 表决过程中，参与者将告知协调者自己的决策：
    同意：事务参与者本地作业执行成功
    取消：本地作业执行故障
• 提交阶段（commit phase）
  • 协调者将基于第一个阶段的投票结构进行决策：提交或取消
  • 当且仅当所有的参与者同意提交事务，协调者才通知所有的参与者提交事务
  • 否则协调者将通知所有的参与者取消事务
  • 参与者在接收到协调者发来的消息后执行响应的操作

http://blog.csdn.net/shenlan211314/article/details/7283948
摘抄一段：
阶段1：

1. A发邮件给B、C和D，提出下周三去爬山，问是否同意。
2. 那么此时A需要等待B、C和D的邮件。
3. B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。
4. 由于某种原因，D白天没有查看邮件。
5. 那么此时A、B和C均需要等待。
6. 到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
   阶段2：
7. 此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。
8. 那么A将发邮件通知B、C和D，下周三爬长城活动取消。
9. 此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。
   要是上面D一直不回复，那么不是A、B阻塞到永久了？

简单讲讲CAP/base/paxos算法。

CAP

一个分布式系统不可能同时满足一致性Consistency、可用性Avaiablity、分区容错性Partition tolerance这三个基本需求，最多只能满足其中的两项。

• 一致性 分布式环境中，一致性指多个数据副本之间能否保持一致的特性。
  • 在一致性要求下，当一个系统在数据一致的状态下执行更新操作后，
  • 应该保证系统的数据任然处于一致的状态。
• 可用性 系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总能在有限的时间内返回结果。
  • 有限时间内
    对于用户的一个操作请求，系统在指定时间内返回处理结果，则系统是可用的
    如果超过指定时间，则系统是不可用的
  • 返回正常结果
    系统完成处理用户请求后，返回正常响应结果，不是异常
• 分区容错性 分布式系统在遇到任何网络分区故障时，任然需要能够保证对外提供满足一致和可用的服务，除非是整个网络环境都发生了故障
  应用组合
• 放弃P 就是放弃系统可扩展性
• 放弃A 遇到网络分区或者其他故障，受影响服务停止服务，即不可用
• 放弃C 放弃强一致性，在一段时间窗口内无法实时保证数据的一致性
  选择PA或者PC，P是不能放弃的

base

CAP演化而来，即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方法来使系统最终一致性。

• Basically Available 基本可用
  指分布式系统出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用
  • 响应时间上的损失
    当出现故障时，响应时间增加
  • 功能上的损失
    当流量高峰期时，屏蔽一些功能的使用以保证系统稳定性-服务降级
• Soft state 软状态
  与硬状态相对，指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的构成存在延时。
• Eventually consistent 最终一致性
  强调系统中所有的数据副本，在经过一段时间的通报后，最终能够达成一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

最终一致性分为:

• 因果一致性 Causal consistency
  A进程更新完数据后通知B进程，B进程在A进程更新后的最新值上操作
• 读己之所写 Read your writes
  进程A更新一项数据后，它总是能访问到自己更新过的最新值
• 会话一致性 Session consistency
  将数据一致性框定在会话当中，在一个回话当中实现读己值所写的一致性。
  即更新后，客户端在同一个会话中始终能肚带该项数据的最新值
• 单调读一致性 Monotonic read consistency
  如果一个进程从系统中读取一个数据项的某个值，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值
• 单调写一致性 Monotoic write consistency
  一个系统需要保证来自同一个进程的写操作被顺序执行。

BASE定理通过牺牲一致性来获得可用性，并允许数据在一段时间是不一致的，但最终达到一致状态

paxos

三类角色

• follower
• candidate
• leader

1. 初始阶段所有节点都是follower，当folower监听听不到leader，将自己置为candidate，发起投票选举leader
2. follower成为candidate的超时时间，每个follower都有随机超时时间，谁先timeout，谁先成为candidate，并给自己投一票，再向其他节点发起投片邀请
3. 如果其他节点在这轮选举还没有投过票，那么就给candidate投票，然后重置自己的选举timeout
4. 如果首先超时的candidate得到大多数的投票，将成为leader，之后定时向follower发送心跳
5. 如果两个follower同时成为candidate，并得到相同票数，则其他follower选择timeout后成为candidate，继续开始从新一轮选举leader

https://segmentfault.com/a/1190000004468442 https://segmentfault.com/a/1190000004474543