MySQL8.0 redo log优化概述和线程模型简介

       本篇内容介绍了“MySQL8.0 redo log优化概述和线程模型介绍”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
 
1 MySQL redo_log简要回顾
 
       在MySQL 5.7中写性能将受限于redo_log的同步操作，特别是在多cpu，存储设备很快的情况下，MySQL 5.7 redo_log的设计无法有效利用存储设备性能，因此需要重新设计。MySQL 5.7瓶颈在于mtr将在把log写到log buffer时加log_sys_t::mutex锁，之后该mtr把dirty page加入flush list中时，为了保证全局有序，会加 log_sys_t::flush_order_mutex锁。如果其他用户线程的mtr要把log写到log buffer，需要等待log_sys_t::mutex，同时为了保证全局lsn有序，其他用户线程的mtr即使要往其他flush list中加数据也需要等待log_sys_t::flush_order_mutex锁，这两把锁是MySQL 5.7中redo_log的主要性能瓶颈。
 
2 redo log优化概述
  
log_writer：负责将日志从log buffer写入磁盘，并推进write_lsn(原子数据)
log_flusher：负责fsync，并推进flushed_to_disk_lsn(原子数据)
log_write_notifier：监听write_lsn，唤醒等待log落盘的用户线程（根据flush_log_at_trx_commit设置，用户commit操作会等待write_lsn推进）
log_flush_notifier：监听flushed_to_disk_lsn，唤醒等待log fsync的用户线程。
 
log_closer：1、在正常退出时清理所有redo_log相关lsn\log buffer相关数据结构；2、定期清理recent_closer的过老数据（recent_closer所用之后详述）
 
log_checkpointer：定期做checkpoint检查，根据flush list刷dirty page情况推进check point，释放log buffer等
 
 
1 线程同步数据结构
 
异步线程之间通过2种数据结构进行数据同步：原子读写（atomic ）和Link_buf。原子读写是c++11针对多核cpu的一个新特性，在不加锁的情况下，对一个64位数据的原子读写。
 
Link_buf是MySQL新实现的数据结构，逻辑上是循环数组，数组下标表示start lsn，数据内容是lsn长度，数据类型为原子类型，如果数据内容（lsn 长度）为0表示这个slot为空 。每个通过合理的std::atomic_thread_fence(std::memory_order_release) / std::atomic_thread_fence(std::memory_order_acquire)操作，保证对里面不同slot的lsn读写的无锁并发。