爱站程序员基地1. 引言
云原生数据库跟分布式mpp数据库是有差异的，虽然两者都是计算与存储分离，但是在资源的占用上有所不同。云原生数据库是shard everything架构，其依赖的存储资源、内存资源、事务资源在云中都是共享、弹性伸缩的。由分布式文件系统提供按需分配、租户隔离的块存储，由分布式内存池提供buffer pool占用的大块内存。分布式mpp数据库则是shard nothing架构，其依赖的存储资源、内存资源、事务资源是单个物理节点上的资源，在SQL计算层进行了分布式计算逻辑的分发。
本文重点介绍共享存储，如果分布式文件系统的iops、每秒刷盘数能够比单个物理节点上的性能线性提升，那么云原生数据库mysql的tps也会随之提升，而且mysql的原生SQL语法都是支持的，包括嵌套子查询、存储过程、函数等。分布式mpp在SQL计算层做分布式计算逻辑的分发，这些可能会被裁减掉。
单机mysql的事务型存储引擎innodb的表空间数据存储依赖于单个linux节点的VFS提供的posix标准的文件操作接口。VFS作为各个具体文件系统（ext4、xfs、ext3等）的抽象层，屏蔽了各个具体文件系统的实现差异，对应用层提供了统一、标准的posix文件操作接口。类似于阿里云的polardb对polarfs的依赖，其实polardb就是mysql的内核源码的二次开发而成的。本文重点罗列云原生数据库mysql在各个场景下对posix文件操作接口需求。
分布式弹性文件系统要具体地实现这些接口，各个接口的语义要完全符合posix标准。并提供mount挂载的功能，将其实现的具体接口注册到VFS内部，mysql将表空间放置到挂载了分布式弹性文件系统的路径下，innodb内部对表空间文件操作时候，实际上就调用了分布式文件系统提供的文件操作的api。
innodb的表空间有用户表空间、系统表空间、Redo日志、Undo表空间。本文重点分析用户表空间对文件操作接口的需求，应该也涵盖了其余的表空间对文件操作接口的需求。
用户对用户表空间的操作主要有两类，一类是表空间数据的读写，另一类是表空间DDL操作，对应到posix标准的文件操作接口，一类是文件数据读写IO，另一类是文件的元数据操作。
2. 表空间数据的读写操作
2.1同步IO
同步IO会阻塞调用线程，直到IO完成，调用线程才返回，pwrite/pread函数是线程安全的同步IO，lseek+read/write函数非线程安全，需要加互斥锁，并发量大的时候，对性能有一定的影响。以下几种场景下，会使用同步IO。
场景一. linux不支持native aio， Page cleaner线程刷脏，同步写
从buffer pool中刷脏页时候，如果不支持native aio，则通过simulated aio模拟异步写进行dirty page的写入表空间操作，本质上是同步写
调用栈：
buf_flush_page_cleaner_worker → pc_flush_slot → buf_flush_do_batch → buf_do_flush_list_batch → buf_flush_page_and_try_neighbors → buf_flush_try_neighbors → buf_flush_page → buf_flush_write_block_low → fil_io(sync=false) → os_aio → os_aio_func →AIO::wake_simulated_handler_thread
场景二. 刷脏时，如果double write buffer写满，将double write buffer中数据写入系统表空间ibdata文件，同步写
调用栈：
buf_flush_page → buf_dblwr_flush_buffered_writes → fil_io(sync=true)
场景三. 事务buffer中数据写入Redo log file，同步写
调用栈：
innobase_commit_low → trx_commit_for_mysql → trx_commit → trx_commit_in_memory → trx_flush_log_if_needed_low → log_write_up_to → log_group_write_buf → log_group_write_buf → fil_io(sync=true)
场景四，用户线程触发的数据块请求读写，同步读写
调用栈：
ha_innobase::index_read → row_search_mvcc → row_sel_get_clust_rec_for_mysql→ buf_page_get_gen → buf_read_page → buf_read_page_low → fil_io(sync=true)
2.2异步IO
异步IO不会阻塞调用线程，提交IO请求后，调用线程就返回，可以做其余的操作，后台线程会轮询IO的完成情况，如果执行完成可以调用相关的回调函数。
在支持native aio的情况下，innodb的后台 Page cleaner线程刷脏，预读走的就是异步IO流程，主要以下两个场景。
场景一. linux支持native aio ，Page cleaner线程刷脏，异步写
从buffer pool中刷脏页时候，如果支持native aio，则通过 io_submit异步io接口进行dirty page的表空间写入操作。
buf_flush_page_cleaner_worker → pc_flush_slot → buf_flush_do_batch → buf_do_flush_list_batch → buf_flush_page_and_try_neighbors → buf_flush_try_neighbors →buf_flush_page → buf_flush_write_block_low → fil_io(sync=false)→ os_aio → os_aio_func → AIO::linux_dispatch → io_submit
场景二. 线性或者逻辑预读，异步读
逻辑预读调用栈：
ha_innobase::index_read → row_search_mvcc → row_sel_get_clust_rec_for_mysql → buf_page_get_gen → buf_read_ahead_random → fil_io(sync=false)
线性预读调用栈：
ha_innobase::index_read → row_search_mvcc → row_sel_get_clust_rec_for_mysql → buf_page_get_gen → buf_read_ahead_linear→ fil_io(sync=false)
2.3 刷盘
如果innodb_flush_method设置了O_DSYNC，日志文件(ib_logfileXXX)使用O_SYNC打开，因此写完数据不需要调用函数fsync刷盘，数据文件(ibd)使用default模式打开，因此写完数据需要调用fsync刷盘。
如果innodb_flush_method设置了fsync或者不设置，数据文件和日志文件都使用default模式打开，写完数据都需要使用fsync来刷盘。
如果innodb_flush_method设置了O_DIRECT，日志文件(ib_logfileXXX)使用default模式打开，写完数据需要调用fsync函数刷盘，数据文件(ibd)使用O_DIRECT模式打开，写完数据需要调用fsync刷盘。
如果innodb_flush_method设置为O_DIRECT_NO_FSYNC，文件打开方式与O_DIRECT模式类似，区别是，数据文件写完后，不调用fsync来刷盘，主要针对O_DIRECT能保证文件的元数据也落盘的FS
如果使用linux native aio，innodb_flush_method一定要配置成O_DIRECT，否则会退化成同步IO。
3. 表空间DDL操作
3.1 create table
创建表时候调用，调用流程如下：
ha_innobase::create → dict_build_tablespace_for_table → fil_idb_create
依次依赖于os_file_create 、os_file_flush、os_file_set_size、os_file_close、os_file_delete，这些函数依次依赖于open\\ fsync\\lseek\\close\\u16c0nlink posix文件标准接口。
3.2 drop table
删除表的时候调用，调用栈如下。
ha_innobase::delete_table → row_drop_table_for_mysql → row_drop_single_table_tablespace → fil_delete_tablespace → unlink
3.3 rename table
重命名表的时候调用，调用栈如下。
ha_innobase::rename_table → row_rename_table_for_mysql → row_rename_table_for_mysql → dict_table_rename_in_cache→ fil_rename_tablespace → rename
3.4 truncate table
截断表时候调用，默认表空间截留4个page的大小。调用栈如下。
ha_innobase::truncate → row_truncate_table_for_mysql → row_truncate_complete → truncate_t::truncate → os_file_truncate_posix → ftruncate
3.5 extend tablespace
innodb表空间文件大小是动态扩展的，如果表空间中的数据页不够，则需要对表空间文件进行预扩展，比如往聚集索引中大量插入数据的时候。调用栈如下
row_ins_clust_index_entry_low → btr_cur_pessimistic_insert → fsp_try_extend_data_file → fsp_try_extend_data_file → fil_space_extend → posix_fallocate
4.posix标准的文件操作接口列表
4.1 文件元数据操作
open(const char *__file, int __oflag, …)close (int __fd);rename (const char *__old, const char *__new)fcntl(int __fd, int __cmd, ...)unlink(const char *__name)mkdir(const char *__path)rmdir(const char *__path)ftruncate(int __fd, __off64_t __length)posix_fallocate(int __fd, __off64_t __offset,__off64_t __len)
4.2 同步IO接口
lseek(int __fd, __off64_t __offset, int __whence)read(int __fd, void *__buf, size_t __nbytes)write(int __fd, const void *__buf, size_t __n)pread(int __fd, void *__buf, size_t __nbytes, __off64_t __offsetad0)pwrite(int __fd, const void *__buf, size_t __nbytes, __off64_t __offset)fsync(int __fd)
4.3 异步IO接口
io_setup(int maxevents, io_context_t *ctxp);io_destroy(io_context_t ctx);io_submit(io_context_t ctx, long nr, struct iocb *ios[]);io_cancel(io_context_t ctx, struct iocb *iocb, struct io_event *evt);io_getevents(io_context_t ctx, long min_nr, long nr, struct io_event *events, struct timespec *timeout);
4.4 挂载
mountumount
4.5 杂项
其余文件属性、权限类的操作，就不一一列举了。
