网站怎么做直播功能,一般注册公司要多少钱,婚庆公司有哪些服务,做情趣网站违法吗来源 | 阿丸笔记封图| CSDN下载于视觉中国提到MySQL的事务#xff0c;我相信对MySQL有了解的同学都能聊上几句#xff0c;无论是面试求职#xff0c;还是日常开发#xff0c;MySQL的事务都跟我们息息相关。而事务的ACID#xff08;即原子性Atomicity、一致性Consistency、… 来源 | 阿丸笔记封图| CSDN下载于视觉中国提到MySQL的事务我相信对MySQL有了解的同学都能聊上几句无论是面试求职还是日常开发MySQL的事务都跟我们息息相关。而事务的ACID即原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability可以说涵盖了事务的全部知识点所以我们不仅要知道ACID是什么还要了解ACID背后的实现只有这样无论在日常开发还是面试求职都能无往而不利。本篇内容将介绍原子性、一致性、持久性相关实现由于这部分内容可能很多人会相对陌生因为日常业务开发可能不太会去接触和深究但是了解完后你对MySQL会有更深刻的认识。基本概念原子性整个事务是不可分割的最小单位事务中任何一个语句执行失败所有已经执行成功的语句也要回滚整个数据库状态要恢复到执行事务前到状态。一致性事务将数据库从一种状态转变为下一种一致的状态。在事务的前后数据库的完整性约束没有被破坏。事务的acid不是完全正交的尤其是一致性可能跟原子性、隔离性都有一定关系后面会看到持久性事务一旦提交那么就是永久性的不会因为宕机等故障导致数据丢失外力影响不保证比如磁盘损害。持久性是保证了数据库的高可靠性High Reliability而不是高可用性(Hign Availability)。高可用性并不能通过事务来保证。持久性的实现MySQL的innoDB存储引擎使用Redo log保证了事务的持久性。当事务提交时必须先将事务的所有日志写入日志文件进行持久化就是我们常说的WALwrite ahead log机制这个技术是保障持久性的关键技术在HBase中也扮演重要角色有兴趣的同学可以参考我之前的HBase文章。这样才能保证断电或宕机等情况发生后已提交的事务不会丢失这个能力称为 crash-safe。下面深入聊一聊redo log的机制给大家更深刻的理解。Redo log包括两部分重做日志缓冲redo log buffer和重做日志文件redo log file前者是易失的缓存后者是持久化的文件。举一个事务的例子步骤1:begin;步骤2:insert into t1 …r步骤3:insert into t2 …步骤4:commit;这个事务的写入过程实际拆解如下innodb缓冲池的概念本文就不展开说明了以后有机会可以展开说一下。重点关注在这个事务提交前将 redo log 的写入拆成了两个步骤prepare 和 commit这就是两阶段提交”。为什么要采用两阶段提交呢实际上两阶段提交是分布式系统常用的机制。MySQL使用了两阶段提交后也是为了保证事务的持久性。Redo log 和bingo 有一个共同的数据字段叫 XID,崩溃恢复的时候会按顺序扫描 redo log。假设在写入binlog前系统崩溃那么数据库恢复后顺序扫描 redo log碰到只有 parepare、而没有 commit 的 redo log就拿着 XID 去 binlog 找对应的事务而且binlog也没写入所以事务就直接回滚了。假设在写入binlog之后事务提交前数据库崩溃那么数据库恢复后顺序扫描 redo log碰到既有 prepare、又有 commit 的 redo log就直接提交保证数据不丢失。这个事务要往两个表中插入记录插入数据的过程中生成的日志都得先写入redo log buffer 等到commit的时候才真正把日志写到 redo log 文件。当然这里不绝对因为redo log buffer可能因为其他原因被迫刷新到redo log。而为了确保每次日志都能写入日志文件在每次将重做日志缓冲 写入 重做日志文件 后InnoDB存储引擎都需要调用一次fsync操作确保写入了磁盘。对于redo log的持久化可以如下图所示。1先写入redo log buffer在蓝色区域。2写入redo log file但是还没有fsync这时候是处于黄色的位置处于系统缓存。3调用fsync真正写入磁盘。为了控制 redo log 的写入策略InnoDB 提供了 innodb_flush_log_at_trx_commit 参数它有三种可能取值设置为 0 的时候表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;设置为 1 的时候表示每次事务提交时都将 redo log 直接持久化到磁盘设置为 2 的时候表示每次事务提交时都只是把 redo log 写到 page cache。binlog的写入和redo log一样也是包括bingo cache和bingo file同样跟上面的三色层次类似当然binlog是server层的不是存储引擎层的包括log buffer、文件系统page cache、hard disk。写入page cache 和 fsync到disk 的时机是由参数 sync_binlog 控制的sync_binlog0 的时候表示每次提交事务都只 写入文件系统的page cache不 fsyncsync_binlog1 的时候表示每次提交事务都会执行 fsyncsync_binlogN(N1) 的时候表示每次提交事务都写入文件系统的page cache但累积 N 个事务后才 fsync。如果主机发生异常重启会丢失最近 N 个事务的 binlog 日志通常我们说 MySQL 的“双 1”配置指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说一个事务完整提交前需要等待两次刷盘一次是 redo logprepare 阶段一次是 binlog。特别需要区分的是redo log和binlog的不同。这也是经常在面试中可能会问到的两种日志的差异。注意有这么几点不同产生位置不同。redo log是innodb的存储引擎产生的而binlog是数据库的server层实现的。换句话说如果你使用MySQL换其他存储引擎那么可能没有redo log但是还是会有binlog。日志记录的内容形式不同。binlog是一种逻辑日志记录对应的SQL语句而redo log记录了物理日志是针对每个数据页的修改。日志写入时间不同。binlog只有在事务提交后完成一次写入对于一个事物而言在binlog中只有一条记录。而redo log在事务进行中不断被写入而且是并发写入的不是顺序写入的。保存方式不同。redo log 是循环写的空间固定会用完binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个并不会覆盖以前的日志。原子性的实现Undo log保证了事务的原子性。在对数据库进行修改时innoDB引擎除了会产生redo log还会产生undo log。InnoDB实现回滚靠的是undo log当事务对数据库进行修改时InnoDB会生成对应的undo log如果事务执行失败导致事务需要回滚就利用undo log中的信息将数据回滚到修改之前的样子。有人认为undo log是redo log的逆过程其实是不对的。两个日志文件其实都能看作是一种对数据的恢复操作redo log恢复事务导致的数据页的修改而undo log能够恢复数据记录到某个特定的版本。所以redo log是一种物理日志数据页的修改而undo log是一种逻辑日志数据记录。undo log还要另外一个重要作用就是用于mvcc中进行多版本控制也就是实现事务隔离性的基础当用户读取一行记录时如果这个记录已接被其他事务占用那么当前事务就可以通过undo读取之前的行版本信息用来实现非锁定读取就是“快照读”。事务隔离性的问题可以看我上一篇文章 跟面试官侃半小时MySQL事务隔离性从基本概念深入到实现 。一致性的实现就像一开始在定义的时候介绍的事务的ACID性质不是完全正交的尤其是一致性我们可以认为原子性、持久性和隔离性都是为了实现事务的一致性。当然这里的一致性是指数据库层面的事务一致性。如果说你在应用层面做一个操作给转账者扣钱没给接收者加钱那么这个不一致跟事务的不一致是没有关系的需要开发人员自己做业务逻辑一致性的保证。同时欢迎所有开发者扫描下方二维码填写《开发者与AI大调研》只需2分钟便可收获价值299元的「AI开发者万人大会」在线直播门票!推荐阅读你公司的虚拟机还闲着基于 Jenkins 和 Kubernetes 的持续集成测试实践了解一下
北京四环堵车引发的智能交通大构想
400 多行代码超详细中文聊天机器人开发指南 | 原力计划
三大运营商将上线 5G 消息苹果谷歌联手追踪 30 亿用户jQuery 3.5.0 发布 | 极客头条比特币当赎金WannaRen 勒索病毒二度来袭从 Web 1.0到Web 3.0详析这些年互联网的发展及未来方向真香朕在看了
