面试题答案
一键面试1. 事务提交类型
- 同步提交（Sync Commit）：在同步提交模式下，事务等待binlog真正写入磁盘才完成提交操作。这确保了事务的持久性，但可能会因为磁盘I/O操作而影响性能。
- 异步提交（Async Commit）：事务在将binlog写入到内存中的缓冲区后就可以完成提交，不必等待binlog实际写入磁盘。这可以显著提高事务提交的速度，但在系统崩溃时可能丢失部分未写入磁盘的binlog。
2. 协调机制
- 组提交（Group Commit）：MariaDB利用组提交机制来提高binlog写入的效率。多个事务可以在同一时间点进行提交，将它们的binlog批量写入磁盘。当一个事务准备提交时，它会加入到一个等待提交的事务组中。只有当组中的所有事务都准备好后，才会将整个组的binlog一次性写入磁盘。
- FLUSH - SYNC - RELEASE流程：
- FLUSH阶段：事务将binlog从内存缓冲区刷新到文件系统缓存（page cache），但并不保证写入磁盘。多个事务可以并行执行此步骤。
- SYNC阶段：将文件系统缓存中的binlog真正写入磁盘。这个阶段通常由一个专门的线程（sync线程）负责，同一时间只有一个事务组可以进行SYNC操作。
- RELEASE阶段：事务完成提交，释放相关的资源，通知其他等待的事务。
3. 锁机制
- 队列锁（Queue Lock）：为了协调事务加入等待提交的事务组，MariaDB使用队列锁。事务在准备提交时获取队列锁，将自己加入到事务组队列中，然后释放队列锁。这确保了事务按顺序加入事务组。
- Sync锁：在SYNC阶段，为了保证同一时间只有一个事务组进行磁盘写入操作，使用Sync锁。持有Sync锁的事务组可以将binlog写入磁盘，其他事务组需要等待该锁释放。
4. 线程调度
- 主事务线程：负责执行事务逻辑，生成binlog，并将其发送到binlog缓冲区。在提交阶段，主事务线程按照FLUSH - SYNC - RELEASE流程协调事务的提交。
- Sync线程：专门负责执行SYNC操作，将文件系统缓存中的binlog写入磁盘。Sync线程由主事务线程唤醒，当有事务组准备好进行SYNC操作时，主事务线程会通知Sync线程。
5. 一致性保证
- Write - Ahead Logging（WAL）：MariaDB遵循WAL原则，在数据实际修改之前，先将binlog写入磁盘。这确保了即使系统崩溃，也可以通过重放binlog来恢复未完成的事务，保证数据的一致性。
- 两阶段提交（2PC）：在组提交过程中，MariaDB实际上也应用了两阶段提交的思想。FLUSH阶段类似于准备阶段，事务将binlog准备好；SYNC阶段类似于提交阶段，确保binlog持久化到磁盘。通过这种方式，保证了所有参与组提交的事务要么全部成功提交，要么全部回滚，从而维护了binlog写入的一致性。