石景山企业网站建设,大型网络游戏排行榜前十,php网站开发需求文档,做个企业网网站怎么做重要概念
事务的ACID
原子性#xff08;Atomicity#xff09;#xff1a;即不可分割性#xff0c;事务中的操作要么全不做#xff0c;要么全做一致性#xff08;Consistency#xff09;#xff1a;一个事务在执行前后#xff0c;数据库都必须处于正确的状态#xf…重要概念
事务的ACID
原子性Atomicity即不可分割性事务中的操作要么全不做要么全做一致性Consistency一个事务在执行前后数据库都必须处于正确的状态满足完整性约束隔离性Isolation多个事务并发执行时一个事务的执行不应影响其他事务的执行持久性Durability事务处理完成后对数据的修改就是永久的即便系统故障也不会丢失
脏读、幻读、不可重复读
脏读读取了未提交的数据不可重复读事务A期间读取多次bb被其他事务影响导致值不可重复幻读幻读和不可重复读有点像它是事务A期间统计多次同一批数据统计结果不一样。原因是被其他事务影响。它们的区别主要在于前者读取精确的某几条数据后者则是范围统计——多版本不好控制
主从复制的原理
主数据库有个bin log记录了所有sql语句把主数据库的bin log的语句复制到从数据库从数据库在relay log重做日志中再执行一遍这些sql
具体而言
主数据库启用输出线程输出bin log从数据库IO线程负责从主数据库里拉取bin log写入到relay logsql线程将relay log重做
三大日志
bin log、redo log和undo log
bin log是归档日志用于主从复制、数据备份等。 redo log是重做日志用于实现事务持久性。在事务在提交时断电重启后可以正常从中恢复。 undo log为回滚日志用于实现事务的原子性即当事务失败时可以全部操作都取消。
bin log和undo log都是MySQL里边服务层的概念它记录的是逻辑记录例如完成了什么SQL。而redo log是存储层的物理操作日志例如“在某个数据页上做了更改”。 在执行更新语句过程会记录 redo log 与 binlog 两块日志以基本的事务为单位redo log 在事务执行过程中可以不断写入而 binlog 只有在提交事务时才写入所以 redo log 与 binlog 的写入时机不一样。
buffer与同步
既然是日志那就躲不开缓存和落盘策略这当然也是很通用的一些解决实践。这里以redo log为例
落盘时机可以通过配置来指定
0事务提交不落盘根据异步同步线程的时间来定通常是1s1每次事务提交都落盘2写入pagecache介于0和1之间
日志提交的事务
在进行数据库操作的时候需要同时操作多个日志这个时候如何保证事务性呢例如宕机之后如何确保binlog和redo log的数据是一致的 这和[[分布式事务]]做的事情基本是一样的。MySql中采用两阶段进行日志的事务提交。
将redo log拆成两个阶段最终提交阶段在binlog完成之后再提交。故障恢复的时候不管在什么阶段一切认准binlog的提交记录。即使在redolog commit期间出错那么只要binlog落库成功说明redolog一定parepare完成可以恢复提交。
这又侧面印证了一个想法分布式事务其实本质上是把一件很大的、多阶段的过程拆解细分尽可能把最终这个影响数据一致的过程缩小到最小粒度尽管无法完全消除尽可能减少出错的可能性。例如上述例子就是把耗时的redolog写入过程拆出去缩小到最终redo log的提交这个更短、更细粒度的过程上。
MVCC如何实现
copy on write
MVCC其实体现的是copy on write的一种思想——追求数据不变性那么就直接复制一份快照。 数据库这么大的数据量当然不可能是真的复制一整个库、一整个表只需要复制相应的行就可以了。那么MySQL到底是怎么实现的呢 这是必然是一个非常复杂的机制涉及到并发SQL复杂操作、多版本数据、各个事务之间实时的可见性管控。 核心的有两点 数据库通过两个核心隐藏列来完成多版本记录
DB_TRX_ID当前事务ID。单调递增因而可以通过大小确定当前事务和其他事务的可见性——对比事务ID大小即可。例如事务ID小于它的就可见大于它的就不可见。你可以理解这个就是版本。DB_ROLL_PTR。回滚指针指向对应的redo log记录。上边记录了“版本号”那么我们就会好奇copy on write中的精髓copy又是怎么体现的呢答案就是通过回滚指针。它不会直接复制一行出来而会在原行上边修改如果需要找到上一个版本就通过回滚指针找到redo log从而找到上一个版本。
从插入和更新来分析实际分析一下 insert由于是新增数据所以不需要redo log指针只需要记录事务id。
update更上边分析一样除了记录事务ID还得记录回滚指针。
第二次修改这里重点来了多版本如何copy呢答案是拉链
可见性保证
事务之间可见性的如何保证这个也是一大难题。 大致描述一下我的理解MySQL在开启事务的时候会收集当前活跃的事务列表于是它就可以通过事务ID加上上边的多版本数据去分析当前存在的数据变更自己可见的是哪些不可见的是哪些。 下边是当前可视视图的声明。
class ReadView {
private:trx_id_t m_low_limit_id; /* 目前出现最大的事务ID大于等于这个 ID 的事务均不可见 */trx_id_t m_up_limit_id; /* 小于这个 ID 的事务均可见 */trx_id_t m_creator_trx_id; /* 创建该 Read View 的事务ID */trx_id_t m_low_limit_no; /* 事务 Number, 小于该 Number 的 Undo Logs 均可以被 Purge */ids_t m_ids; /* 创建 Read View 时的活跃事务列表 */m_closed; /* 标记 Read View 是否 close */
}
处于最大、最小ID之间的就是活跃但不可见的事务列表。
事务的实现
好了这下我们有充足的知识可以来讨论如何实现事务了。
整体方案
原子性undo log事务中断恢复持久性redo log同步写回磁盘提交断电时可恢复隔离性通过读写锁和MVCC来实现的一致性通过上述三者来实现的。
隔离性对应四种隔离级别
READ UNCOMMITTED 读不加锁不排斥写。
优点读写并行性能高缺点造成脏读
READ COMITTED 读不加锁读写分离。但这里MVCC的方式是每次读的时候都会读取不同版本这会造成不可重复读问题。
当然也有幻读问题。
REPEATABLE READ(Mysql默认隔离级别)
最简单的方式读写锁实现让读写串行 优点实现起来简单缺点无法做到读写并行
MVCC 通过版本控制解决版本不同问题产生不可重复读的问题
优点读写并行缺点实现的复杂度高依然存在幻读的问题
InnoDB是可以解决幻读的大致的思想也很简单 Next-key Lock对查询间隙进行加锁不让插入自然也就不会有幻读问题。
SERIALIZABLE 注 可线性化和可串行化听起来很像感觉也很像。其实不太一样两者是分布式数据库中的一致性模型但后者主要指事务中的一种隔离级别。 我的理解是最大的区别在于可线性化要求对于所有事件都必须满足所有时刻的先后可见性。而可序列化仅需要保证多个并行的事务和某个事务序列结果一致即可。 这非常像Java中重排和happen-before的理念。
参考
https://blog.csdn.net/weixin_36380516/article/details/107572412https://javaguide.cn/database/mysql/innodb-implementation-of-mvcc.html#readview
