十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
1、原子性:在整个操作的事务中,要么全部成功,要么全部失败。
创新互联云计算的互联网服务提供商,拥有超过13年的服务器租用、成都服务器托管、云服务器、虚拟主机、网站系统开发经验,已先后获得国家工业和信息化部颁发的互联网数据中心业务许可证。专业提供云主机、虚拟主机、域名注册、VPS主机、云服务器、香港云服务器、免备案服务器等。
2、隔离性:所谓隔离性,就是每个事务执行的时候,相互之间不会受到影响,都是单独的事务。
3、一致性:也就是说事务在执行之后,必须和之前的数据保持一致。
4、持久性:事务一旦提交,就会持久化到数据库中,不能回滚。
undolog可以实现事务的原子性,还可以用来实现MVCC。其原理是,(开启事务后)在操作任何数据前,先将原数据备份到undolog,然后对数据进行修改,如果此过程中出现异常,或执行了rollback语句,可利用undolog中备份的数据恢复到事务开始之前的状态。
假设有A、B两个数据,值分别为1,2。 进行+2的事务操作。
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录B=2到undo log.
E.修改B=4.
F.将undo log写到磁盘。
G.将数据写到磁盘。
H.事务提交
对于数据的操作,都是先读到内存中,然后在内存中修改,最后将数据写到磁盘。
之所以能保证原子性,是因为:
A. 更新数据前记录Undo log。
B. 为了保证持久性,必须将数据在事务提交前写到磁盘。只要事务成功提交,数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃,undo log是完整的,可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺点:每个事务提交前将数据和Undo Log写入磁盘,这样会导致大量的磁盘IO,因此性能很低。
所以,为了提升性能,可以在写数据到磁盘前,先写redolog,这就是wal预写日志机制,这样先写redolog日志,数据只需先写到内存,因为redolog是顺序写,而数据落盘则是随机写,要慢得多。 这样,当系统崩溃时,虽然数据没有持久化,但有redolog撑着,数据也不会丢。(innodb_flush_log_at_trx_commit 这个参数设置为2时,那么redolog每次不需落盘,而是写到os cache中(一定时间后再flush到磁盘),这样性能又大大提升,只要操作系统不宕,即便mysql宕了,数据也不会丢)
Undo + Redo事务的简化过程
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录A=3到redo log.
E.记录B=2到undo log.
F.修改B=4.
G.记录B=4到redo log.
H.将redo log写入磁盘。
I.事务提交
通过undo保证事务的原子性,redo保证持久性。
但是!!!基于以上的过程,mysql一个事务操作依旧十分繁琐,这也就是其在并发场景下需借助于nosql来提升性能
redolog和undolog属于innodb,而在mysql的server层还有一个binlog,其作用是误操作后需要靠它来恢复数据以及主从复制, mysql在update一行数据的时候:
1.执行器先找引擎取id=n这一行,id是主键,引擎直接用树搜索到这一行
2.执行器拿到引擎给的行数据,把这个值加1,得到新的一行数据,再调用引擎接口写入这行新数据
3.引擎将这行数据更新到内存中,同时将这个更新操作记录到redolog中,此时redolog处于prepare状态,然后告知执行器执行完成,随时可以提交事务
4.执行器生成这个操作的binlig,并写入磁盘
5.执行器调用引擎的提交事务接口,引擎吧刚刚写入的redolog改成提交(commit)状态,更新完成
将redolog的写入拆成两个步骤,prepare和commit,这就是两阶段提交,其目的是为了让两份日志(redolog和binlog)之间的逻辑一致
这两个日志有三点不同:
1.redolog是innodb特有,binlog是mysql server层实现的,所有引擎都可以使用,
2.redolog是物理日志,记录的是在某个数据页上做了什么修改,binlog是逻辑日志,记录的是这个语句的原始逻辑,
3.redolog是循环写的,空间固定会用完,binlog是可以追加写入的,追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。
redolog和binlog互相是不可替代的,redolog的作用是提升数据写入时的性能,并保证事务的持久化特性,以及崩溃恢复的能力,而binlog 是无法支持崩溃恢复,因为它没有能力恢复“数据页”。 而binlog也有着redolog无法替代的功能,一个是归档。redo log 是循环写,写到末尾是要回到开头继续写的。这样历史日志没法保留,redolog 也就起不到归档的作用。还有很多公司有异构系统中使用到的组件(比如es,redis等),这些系统就靠消费 MySQL 的 binlog 来更新自己的数据。关掉 binlog 的话,这些下游系统就没法输入了。总之,由于现在包括 MySQL 高可用在内的很多系统机制都依赖于 binlog,所以“鸠占鹊巢”redo log 还做不到。
原子性, 一个事务 要么完全提交 要么完全回滚,不会介于2者之间。 一致性,一个查询发起后,不管数据发生了多少变化 多少事务,查询结果应当为发起查询时间一致的数据