MySQL · 引擎特性 · IO_CACHE 源码解析

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: 概述在数据库中 IO 的重要性不言而喻,为了更好的管理 IO 操作,大多数数据库都自己管理页数据和刷脏机制(例如 InnoDB 中的 Buffer pool),而不是交给文件系统甚至是操作系统调度。但是对于顺序写入的日志数据,使用文件系统接口方便的多,文件系统 也是以页的形式管理,呈现给应用层的是一片连续可写的空间,管理的单位称为 Sector 大小是 4KB,所以对于 4KB 对齐的地址读写可以避免跨多个 Sector,对文件系统的性能有很大的提高。

概述

在数据库中 IO 的重要性不言而喻,为了更好的管理 IO 操作,大多数数据库都自己管理页数据和刷脏机制(例如 InnoDB 中的 Buffer pool),而不是交给文件系统甚至是操作系统调度。但是对于顺序写入的日志数据,使用文件系统接口方便的多,文件系统 也是以页的形式管理,呈现给应用层的是一片连续可写的空间,管理的单位称为 Sector 大小是 4KB,所以对于 4KB 对齐的地址读写可以避免跨多个 Sector,对文件系统的性能有很大的提高。MySQL 中的 IO_CACHE 的作用就是把连续的文件读写操作,经过缓冲,转化为 4K 对齐的文件读写操作。

0920-iocache1.png

如图所示,对于文件的读写操作如果小于 IO_CACHE 大小,就放到缓冲中,当 IO_CACHE 满了就进行一次 4KB 对齐的写入,如果一次读写超过 IO_CACHE 的大小,就把 4K 对齐的数据进行一次读写,剩余部分放到 IO_CACHE 中,等待下次读写一起合并。

源码解析

IO_CACHE 有不同的类型,定义在 cache_type 中:

enum cache_type
{
  TYPE_NOT_SET= 0, READ_CACHE, WRITE_CACHE,
  SEQ_READ_APPEND		/* sequential read or append */,
  READ_FIFO, READ_NET,WRITE_NET};

常用的 general log, slow log, err log, binlog 主要使用 READ_CACHE, WRITE_CACHE, SEQ_READ_APPEND 几种类型,本文主要介绍这几种。同时 IO_CACHE 也提供支持 AIO 的接口,支持多线程同时访问 IO_CACHE 等,目前来看来应用也不多,暂不涉及。

主要代码在 mysys/mf_iocache.c 中,

READ_CACHE 是读缓冲,WRITE_CACHE 是写缓冲,SEQ_READ_APPEND 同时支持读写,写线程不断 append 数据到文件尾,读线程去 read 数据。append 使用 IO_CACHE::write_buffer, read 使用 IO_CACHE::buffer。当读到 write_buffer 中的数据时,就从 write_buffer 中拿数据。SEQ_READ_APPEND 这种类型在 MySQL 复制模块使用,IO 线程负责 append 数据到 relay log,SQL 线程负责 read 出来应用(考虑下为什么在主库上的写入线程和 Dump 线程之间不是使用这种方法,而是简单的 read-write,因为主库上 order_commit 函数很可能成为性能的瓶颈,和 Dump 线程竞争 append_buffer_lock 似乎并不好),因为 SEQ_READ_APPEND 类型更具有代表性,就以这种类型为例介绍。

基础数据结构

基本的结构是 IO_CACHE,代码中注释写的比较清楚,这里贴一下方便后面看,

typedef struct st_io_cache
{
  /* Offset in file corresponding to the first byte of uchar* buffer. */
  my_off_t pos_in_file;
  /*
    The offset of end of file for READ_CACHE and WRITE_CACHE.
    For SEQ_READ_APPEND it the maximum of the actual end of file and
    the position represented by read_end.
  */
  my_off_t end_of_file;
  /* Points to current read position in the buffer */
  uchar	*read_pos;
  /* the non-inclusive boundary in the buffer for the currently valid read */
  uchar  *read_end;
  uchar  *buffer;				/* The read buffer */
  /* Used in ASYNC_IO */
  uchar  *request_pos;

  /* Only used in WRITE caches and in SEQ_READ_APPEND to buffer writes */
  uchar  *write_buffer;
  /*
    Only used in SEQ_READ_APPEND, and points to the current read position
    in the write buffer. Note that reads in SEQ_READ_APPEND caches can
    happen from both read buffer (uchar* buffer) and write buffer
    (uchar* write_buffer).
  */
  uchar *append_read_pos;
  /* Points to current write position in the write buffer */
  uchar *write_pos;
  /* The non-inclusive boundary of the valid write area */
  uchar *write_end;

  /*
    Current_pos and current_end are convenience variables used by
    my_b_tell() and other routines that need to know the current offset
    current_pos points to &write_pos, and current_end to &write_end in a
    WRITE_CACHE, and &read_pos and &read_end respectively otherwise
  */
  uchar  **current_pos, **current_end;

  /*
    The lock is for append buffer used in SEQ_READ_APPEND cache
    need mutex copying from append buffer to read buffer.
  */
  mysql_mutex_t append_buffer_lock;

  /*
    A caller will use my_b_read() macro to read from the cache
    if the data is already in cache, it will be simply copied with
    memcpy() and internal variables will be accordinging updated with
    no functions invoked. However, if the data is not fully in the cache,
    my_b_read() will call read_function to fetch the data. read_function
    must never be invoked directly.
  */
  int (*read_function)(struct st_io_cache *,uchar *,size_t);
  /*
    Same idea as in the case of read_function, except my_b_write() needs to
    be replaced with my_b_append() for a SEQ_READ_APPEND cache
  */
  int (*write_function)(struct st_io_cache *,const uchar *,size_t);
  /*
    Specifies the type of the cache. 
  */
  enum cache_type type;
  /*
    Callbacks when the actual read I/O happens. These were added and
    are currently used for binary logging of LOAD DATA INFILE - when a
    block is read from the file, we create a block create/append event, and
    when IO_CACHE is closed, we create an end event. These functions could,
    of course be used for other things
  */
  IO_CACHE_CALLBACK pre_read;
  IO_CACHE_CALLBACK post_read;
  IO_CACHE_CALLBACK pre_close;
  /*
    Counts the number of times, when we were forced to use disk. We use it to
    increase the binlog_cache_disk_use and binlog_stmt_cache_disk_use status
    variables.
  */
  ulong disk_writes;
  void* arg;				/* for use by pre/post_read */
  char *file_name;			/* if used with 'open_cached_file' */
  char *dir,*prefix;
  File file; /* file descriptor */
  /*
    seek_not_done is set by my_b_seek() to inform the upcoming read/write
    operation that a seek needs to be preformed prior to the actual I/O
    error is 0 if the cache operation was successful, -1 if there was a
    "hard" error, and the actual number of I/O-ed bytes if the read/write was
    partial.
  */
  int	seek_not_done,error;
  /* buffer_length is memory size allocated for buffer or write_buffer */
  size_t	buffer_length;
  /* read_length is the same as buffer_length except when we use async io */
  size_t  read_length;
  myf	myflags;			/* Flags used to my_read/my_write */
  /*
    alloced_buffer is 1 if the buffer was allocated by init_io_cache() and
    0 if it was supplied by the user.
    Currently READ_NET is the only one that will use a buffer allocated
    somewhere else
  */
  my_bool alloced_buffer;
} IO_CACHE;

初始化

初始化函数是 init_io_cache ,主要会做以下几件事:

  1. 和对应的文件描述符绑定,初始化 IO_CACHE 中各种变量。
  2. 分配 write_buffer 和 read_buffer 的空间。
  3. 初始化互斥变量 append_buffer_lock. (对于 SEQ_READ_APPEND 类型而言)
  4. init_functions 初始化对应的文件读写函数。

其中根据传入的参数 cache_size 分配缓冲空间,一般传入的空间都不算大,例如 Binlog 的 IO_CACHE 初始化传入的大小就是 IO_SIZE(4KB),因为文件系统本身是有 page cache 的,只有调用 fsync 操作才会保证数据落盘,所以 IO_CACHE 就没必要缓冲太多的数据,只做把数据对齐写入的活。但并不是传进来多大空间就分配多大空间,看下代码:

min_cache=use_async_io ? IO_SIZE*4 : IO_SIZE*2;

cachesize= ((cachesize + min_cache-1) & ~(min_cache-1));
for (;;)
{
	if (cachesize < min_cache)
		cachesize = min_cache;
   buffer_block= cachesize;
   if (type == SEQ_READ_APPEND)
		buffer_block *= 2;
	
	if ((info->buffer= (uchar*) my_malloc(buffer_block, flags)) != 0)
   {
		info->write_buffer=info->buffer;
		if (type == SEQ_READ_APPEND)
	  		info->write_buffer = info->buffer + cachesize;
		info->alloced_buffer=1;
		break;					/* Enough memory found */
   }
   if (cachesize == min_cache)
		DBUG_RETURN(2);				/* Can't alloc cache */
   /* Try with less memory */
      cachesize= (cachesize*3/4 & ~(min_cache-1));
}    

最小的分配空间在不使用 AIO 的情况下是 8K,这个后面会用到,SEQ_READ_APPEND 类型会分配两倍空间,因为有读缓冲和写缓冲。如果申请的空间无法满足就试图申请小一点的空间。

init_functions 是根据 IO_CACHE 的类型初始化 IO_CACHE::read_function 和 IO_CACHE::write_function,当缓冲大小没法满足文件 IO 请求的时候就会调用这两个函数去文件中交换数据。

case SEQ_READ_APPEND:
    info->read_function = _my_b_seq_read;
    info->write_function = 0;			/* Force a core if used */
    break;
default:
    info->read_function = info->share ? _my_b_read_r : _my_b_read;
    info->write_function = _my_b_write;
  }

SEQ_READ_APPEND 的写直接调用 my_b_append。

调用接口

主要的接口在 include/my_sys.h 文件中,大多是宏定义形式。简单看几个常用的:

#define my_b_read(info,Buffer,Count) \
  ((info)->read_pos + (Count) <= (info)->read_end ?\
   (memcpy(Buffer,(info)->read_pos,(size_t) (Count)), \
    ((info)->read_pos+=(Count)),0) :\
   (*(info)->read_function)((info),Buffer,Count))

从 IO_CACHE info 中读取 Count 个字节到 Buffer 中,read_pos 是当前读到的位置,相对于 IO_CACHE::buffer,read_end 是缓冲区的末尾,这要要注意的是 read_end 相对于 IO_CACHE::buffer 的长度,并不一定是缓冲的长度,因为在读写过程中会调整缓冲区大小做 4K 对齐。逻辑比较简单,如果缓冲区的有效数据长度不够,那么就调用 read_function 做文件 IO。

#define my_b_write(info,Buffer,Count) \
 ((info)->write_pos + (Count) <=(info)->write_end ?\
  (memcpy((info)->write_pos, (Buffer), (size_t)(Count)),\
   ((info)->write_pos+=(Count)),0) : \
   (*(info)->write_function)((info),(uchar *)(Buffer),(Count)))

从 Buffer 中向 IO_CACHE info 写 Count 个字节数据,逻辑类似,如果写入缓冲不够,就做一次文件 IO。

#define my_b_tell(info) ((info)->pos_in_file + \
			 (size_t) (*(info)->current_pos - (info)->request_pos))

这里 request_pos 是指向 IO_CACHE::buffer 的,而 current_pos 在 setup_io_cache 中初始化为 read_pos 或者 write_pos, 这种设计就可以为不同的 cache type 提供统一的接口。

还有一些非宏定义的接口比如 my_b_seek 等在文件 mysys_iocache2.c 中,不一一介绍,总之文件系统常用的操作在 IO_CACHE 中基本都可以找到。

_my_b_seq_read

以 SEQ_READ_APPEND 类型为例,文件 IO 的函数是 _my_b_seq_read, 整个流程分为三个阶段:

  1. read from info->buffer
  2. read from file description
  3. try append buffer

因为 SEQ_READ_APPEND 类型的读可能会读到 info->write_buffer 中还没来及写到文件系统里的数据,所以第三步就是去写缓冲中读。整个代码的精髓在于计算需要读多少数据才能保证对齐,看下代码:

// 先把 IO_CACHE 里剩下的数据读到 Buffer 里
if ((left_length=(size_t) (info->read_end-info->read_pos))
{
    memcpy(Buffer, info->read_pos, left_length);
    Buffer+=left_length;
    Count-=left_length;
}
//更新 pos_in_file, 如果更新之后超出了 end_of_file, 就去 append_buffer 中读取。
if (pos_in_file=info->pos_in_file +
    (size_t)(info->read_end - info->buffer)) > info->end_of_file)
    goto read_append_buffer;

// diff_length 为了对齐读
diff_length= (size_t)(pos_in_file &(IO_SIZE-1));

// 第二阶段,从文件里读数据
// 一般 IO_CACHE 默认初始化是 2*IO_CACHE,8KB,这个意思是 Count 的大小已经不能放在一个 IO_CACHE
// 的 Buffer 里
if (Count >= (size_t)(IO_SIZE + (IO_SIZE - diff_length)
{
    // 到这里面说明 Count 要读的数据超过了 IO_CACHE 中的 Buffer 大小,直接读到 Buffer
    // 那么读多少比较合适呢?
// 取出高阶的 IO_CACHE,整数个。(Count & (size_t)~(IO_SIZAE-1))
// 但是因为 pos_in_file 相对于 4K 对齐地址还有一定的偏移量,再减去这个偏移,保证整个读取是对齐的
    length=(Count & (size_t)~(IO_SIZE-1))-diff_Lenght;
    if (read_length=mysql_file_read(info->file, Buffer, length..){}
    // update after read
    Count -= read_lenght;
    Buffer += read_leagth;
    pos_in_file += read_length;
    if(read_length != length)
        goto read_append_buffer; // 没有读到想要的长度
    left_length += length;
    diff_length=0;  // no diff length now
}

// IO_CACHE buffer 中还可以读多少数据。
max_length= info->read_length-diff_length;
// 可能会超出文件结尾,需要到 append buffer 读取
if (max_length > (info->end_of_file - pos_in_file)
    max_length= (size_t)(info->end_of_file - pos_in_file)
if (!max_length) // 已经到了文件尾
{
    if (Count) // 如果还有东西要读
        goto read_append_buffer; 去 append buffer 读
}else // 还可以读一些东西
{
    // 读到 info->buffer 里,max_length 要么读到真实文件尾,要么读到 read buffer的尽头
    length= mysql_file_read(info->file, info->bufffer, max_length);
    if (lenth < Count) 还有东西要读
    {
        goto read_append_buffer;
    }
}     

return 0;

read_append_buffer:
{
    // 先看 append buffer 
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
13天前
|
存储 Java
深入探讨了Java集合框架中的HashSet和TreeSet,解析了两者在元素存储上的无序与有序特性。
【10月更文挑战第16天】本文深入探讨了Java集合框架中的HashSet和TreeSet,解析了两者在元素存储上的无序与有序特性。HashSet基于哈希表实现,添加元素时根据哈希值分布,遍历时顺序不可预测;而TreeSet利用红黑树结构,按自然顺序或自定义顺序存储元素,确保遍历时有序输出。文章还提供了示例代码,帮助读者更好地理解这两种集合类型的使用场景和内部机制。
30 3
|
15天前
|
存储 算法 Java
解析HashSet的工作原理,揭示Set如何利用哈希算法和equals()方法确保元素唯一性,并通过示例代码展示了其“无重复”特性的具体应用
在Java中,Set接口以其独特的“无重复”特性脱颖而出。本文通过解析HashSet的工作原理,揭示Set如何利用哈希算法和equals()方法确保元素唯一性,并通过示例代码展示了其“无重复”特性的具体应用。
35 3
|
17天前
|
缓存 JavaScript 前端开发
Vue3与Vue2生命周期对比:新特性解析与差异探讨
Vue3与Vue2生命周期对比:新特性解析与差异探讨
66 2
|
1天前
|
Kubernetes Cloud Native 调度
云原生批量任务编排引擎Argo Workflows发布3.6,一文解析关键新特性
Argo Workflows是CNCF毕业项目,最受欢迎的云原生工作流引擎,专为Kubernetes上编排批量任务而设计,本文主要对最新发布的Argo Workflows 3.6版本的关键新特性做一个深入的解析。
|
6天前
|
存储 关系型数据库 MySQL
MySQL MVCC深度解析:掌握并发控制的艺术
【10月更文挑战第23天】 在数据库领域,MVCC(Multi-Version Concurrency Control,多版本并发控制)是一种重要的并发控制机制,它允许多个事务并发执行而不产生冲突。MySQL作为广泛使用的数据库系统,其InnoDB存储引擎就采用了MVCC来处理事务。本文将深入探讨MySQL中的MVCC机制,帮助你在面试中自信应对相关问题。
16 3
|
6天前
|
缓存 关系型数据库 MySQL
MySQL执行计划深度解析:如何做出最优选择
【10月更文挑战第23天】 在数据库查询性能优化中,执行计划的选择至关重要。MySQL通过查询优化器来生成执行计划,但有时不同的执行计划会导致性能差异。理解如何选择合适的执行计划,以及为什么某些计划更优,对于数据库管理员和开发者来说是一项必备技能。
17 2
|
9天前
|
PHP 数据安全/隐私保护 开发者
PHP 7新特性解析与实践
【10月更文挑战第20天】本文将深入浅出地介绍PHP 7的新特性,包括性能提升、语法改进等方面。我们将通过实际代码示例,展示如何利用这些新特性优化现有项目,提高开发效率。无论你是PHP新手还是资深开发者,都能从中获得启发和帮助。
|
10天前
|
人工智能 Cloud Native Java
云原生技术深度解析:从IO优化到AI处理
【10月更文挑战第24天】在当今数字化时代,云计算已经成为企业IT架构的核心。云原生作为云计算的最新演进形态,旨在通过一系列先进的技术和实践,帮助企业构建高效、弹性、可观测的应用系统。本文将从IO优化、key问题解决、多线程意义以及AI处理等多个维度,深入探讨云原生技术的内涵与外延,并结合Java和AI技术给出相应的示例。
46 1
|
10天前
|
运维 Cloud Native 持续交付
云原生技术解析:从IO出发,以阿里云原生为例
【10月更文挑战第24天】随着互联网技术的不断发展,传统的单体应用架构逐渐暴露出扩展性差、迭代速度慢等问题。为了应对这些挑战,云原生技术应运而生。云原生是一种利用云计算的优势,以更灵活、可扩展和可靠的方式构建和部署应用程序的方法。它强调以容器、微服务、自动化和持续交付为核心,旨在提高开发效率、增强系统的灵活性和可维护性。阿里云作为国内领先的云服务商,在云原生领域有着深厚的积累和实践。
32 0
|
12天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
15 0

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多