###mysql架构

概念上可以分为四层:

  • 接入层:不同客户端通过mysql协议与mysql连接通讯,接入层进行权限验证、连接池管理线程管理等。
  • 服务层:sql解析器、优化器、数据缓冲、缓存等。
  • 存储引擎:常用的MyISAM、InnoDB存储引擎
  • 文件系统:保存数据、索引、日志等。

MVCC

MVCC(Multi Version Concurrency Control)多版本并发控制。
InnoDB可重复读隔离级别中聚集索引叶子节点中保存了回滚指针,指向修改前的存放在undo log中的数据,InnoDB也正是通过回滚指针和undo log实现MVCC和事务回滚

undo log中的内容只是串行化的结果,记录了多个事务的过程,不属于多版本共存。但理想的MVCC是难以实现的,当事务仅修改一行记录使用理想的MVCC模式是没有问题的, 可以通过比较版本号进行回滚,但当事务影响到多行数据时,理想的MVCC就无能为力了。

问题:transaction1修改row1、row2,row1修改失败row2修改成功,此时事务需要回滚row1、row2不需要回滚,此时row1上是没有锁的并且可能被transaction2修改, 但是我们现在回滚row1的内容就可能造成破坏transaction2的结果。

思考:理想MVCC难以实现的根本原因在于企图通过乐观锁代替二段提交。修改两行数据,但为了保证其一致性,与修改两个分布式系统中的数据并无区别,而二提交是目前这种场景 保证一致性的唯一手段。

  • 二段提交的本质是锁定
  • 乐观锁的本质是消除锁定,本质上存在矛盾
  • 理想的MVCC难以实现,Innodb只是借了MVCC这个名字,提供了非阻塞读

redo/undo/bin log

  • redo log:内存中的修改操作都会记录在redo log中,当内存和磁盘中的数据不一致或事物提交时会进行一次flush操作。
  • undo log:记录数据的反向操作,用于操作的撤回和数据的恢复,通过undo log可以实现事务回滚,并且可以根据undo log回溯到某个特定的版本,实现MVCC
  • bin log:binlog是mysql服务层产生的日志,常用来进行数据恢复、数据库复制,常见的mysql主从架构,就是采用slave同步master的binlog实现的, 另外通过解析binlog 能够实现mysql到其他数据源(如ElasticSearch)的数据复制。

redo/bin log一致性保证

为了防止写完bin log但是redo log的事务没提交从而导致的不一致,innodb 使用了两阶段提交,其基本逻辑就是上锁:

InnoDB prepare write/sync redo/undo log (prepare_commit_mutex mysql5.6前)
write/sync Binlog
InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)