Go 存储基础 | 怎么使用 direct io ？
Go 存储编程怎么使用 O_DIRECT 模式？今天就分享这个存储细节，
之前提过很多次，操作系统的 IO 过文件系统的时候，默认是会使用到 page cache，并且采用的是 write back 的方式，系统异步刷盘的。由于是异步的，如果在数据还未刷盘之前，掉电的话就会导致数据丢失。
如果想要明确数据写到磁盘有两种方式：要么就每次写完主动 sync 一把，要么就使用 direct io 的方式，指明每一笔 io 数据都要写到磁盘才返回。
那么在 Go 里面怎么使用 direct io 呢？
有同学可能会说，那还不简单，open 文件的时候 flag 用 O_DIRECT 嘛，然后。。。
是吗？有这么简单吗？提两个问题，童鞋们可以先思考下：
- O_DIRECT 这个定义在 Go 标准库的哪个文件？
- direct io 需要 io 大小和偏移扇区对齐，且还要满足内存 buffer 地址的对齐，这个怎么做到？
O_DIRECT 的知识点
在此之前，先回顾 O_DIRECT 相关的知识。direct io 也就是常说的 DIO，是在 Open 的时候通过 flag 来指定 O_DIRECT 参数，之后的数据的 write/read 都是绕过 page cache，直接和磁盘操作，从而避免了掉电丢数据的尴尬局面，同时也让应用层可以自己决定内存的使用（避免不必要的 cache 消耗）。
direct io 一般解决两个问题：
- 数据落盘，确保掉电不丢失；
- 减少内核 page cache 的内存使用，业务层自己控制内存，更加灵活；
direct io 模式需要用户保证对齐规则，否则 IO 会报错，有 3 个需要对齐的规则：
- IO 的大小必须扇区大小（512字节）对齐
- IO 偏移按照扇区大小对齐；
- 内存 buffer 的地址也必须是扇区对齐；
direct io 模式却不对齐会怎样？读写报错呗，会抛出“无效参数”的错误。
思考问题
为什么 Go 的 O_DIRECT 知识点值得一提？
以下按照两层意思分析思考。
1 第一层意思：O_DIRECT 平台不兼容**划重点：Go 标准库 os 中的是没有 O_DIRECT 这个参数的。**
为什么呢？
Go os 库实现的是各个操作系统兼容的实现，direct io 这个在不同的操作系统下实现形态不一样。其实 O_DIRECT 这个 Open flag 参数本就是只存在于 linux 系统。
以下才是各个平台兼容的 Open 参数 ( os/file.go )。
const (
// Exactly one of O_RDONLY, O_WRONLY, or O_RDWR must be specified.
O_RDONLY int = syscall.O_RDONLY // open the file read-only.
O_WRONLY int = syscall.O_WRONLY // open the file write-only.
O_RDWR int = syscall.O_RDWR // open the file read-write.
// The remaining values may be or'ed in to control behavior.
O_APPEND int = syscall.O_APPEND // append data to the file when writing.
O_CREATE int = syscall.O_CREAT // create a new file if none exists.
O_EXCL int = syscall.O_EXCL // used with O_CREATE, file must not exist.
O_SYNC int = syscall.O_SYNC // open for synchronous I/O.
O_TRUNC int = syscall.O_TRUNC // truncate regular writable file when opened.
)发现了吗？O_DIRECT 根本不在其中。O_DIRECT 其实是和系统平台强相关的一个参数。
问题来了，那么 O_DIRECT 定义在那里？
跟操作系统强相关的自然是定义在 syscall 库中：
// syscall/zerrors_linux_amd64.go
const (
// ...
O_DIRECT = 0x4000
)怎么打开文件呢？
// +build linux
// 指明在 linux 平台系统编译
fp := os.OpenFile(name, syscall.O_DIRECT|flag, perm)2 第二层意思：Go 无法精确控制内存分配地址标准库或者内置函数没有提供让你分配对齐内存的函数。
direct io 必须要满足 3 种对齐规则：io 偏移扇区对齐，长度扇区对齐，内存 buffer 地址扇区对齐。前两个还比较好满足，但是分配的内存地址作为一个小程序员无法精确控制。
先对比回忆下 c 语言，libc 库是调用 posix_memalign 直接分配出符合要求的内存块。go 里面怎么做？
先问个问题：Go 里面怎么分配 buffer 内存？
io 的 buffer 其实就是字节数组嘛，很好回答，最常见自然是用 make 来分配，如下：
buffer := make([]byte, 4096)
那这个地址是对齐的吗？
答案是：不确定。
那怎么才能获取到对齐的地址呢？
划重点：方法很简单，就是先分配一个比预期要大的内存块，然后在这个内存块里找对齐位置。 这是一个任何语言皆通用的方法，在 Go 里也是可用的。
什么意思？
比如，我现在需要一个 4096 大小的内存块，要求地址按照 512 对齐，可以这样做：
- 先分配要给 4096 + 512 大小的内存块，假设得到的地址是 p1 ;
- 然后在 [ p1, p1+512 ] 这个地址范围找，一定能找到 512 对齐的地址（这个能理解吗？），假设这个地址是 p2 ;
- 返回 p2 这个地址给用户使用，用户能正常使用 [ p2, p2 + 4096 ] 这个范围的内存块而不越界；
以上就是基本原理了，童鞋理解了不？下面看下代码怎么写。
const (
AlignSize = 512
)
// 在 block 这个字节数组首地址，往后找，找到符合 AlignSize 对齐的地址，并返回
// 这里用到位操作，速度很快；
func alignment(block []byte, AlignSize int) int {
return int(uintptr(unsafe.Pointer(&block[0])) & uintptr(AlignSize-1))
}
// 分配 BlockSize 大小的内存块
// 地址按照 512 对齐
func AlignedBlock(BlockSize int) []byte {
// 分配一个，分配大小比实际需要的稍大
block := make([]byte, BlockSize+AlignSize)
// 计算这个 block 内存块往后多少偏移，地址才能对齐到 512
a := alignment(block, AlignSize)
offset := 0
if a != 0 {
offset = AlignSize - a
}
// 偏移指定位置，生成一个新的 block，这个 block 将满足地址对齐 512；
block = block[offset : offset+BlockSize]
if BlockSize != 0 {
// 最后做一次校验
a = alignment(block, AlignSize)
if a != 0 {
log.Fatal("Failed to align block")
}
}
return block
}所以，通过以上 AlignedBlock 函数分配出来的内存一定是 512 地址对齐的。
有啥缺点吗？
浪费空间嘛。 命名需要 4k 内存，实际分配了 4k+512 。
3 我太懒了，一行代码都不愿多写，有开源的库吗？
还真有，推荐个：https://github.com/ncw/directio ，内部实现极其简单，就是上面的一样。
使用姿势很简单：
步骤一：O_DIRECT 模式打开文件：
// 创建句柄
fp, err := directio.OpenFile(file, os.O_RDONLY, 0666)封装关键在于：O_DIRECT 是从 syscall 库获取的。
步骤二：读数据
// 创建地址按照 4k 对齐的内存块
buffer := directio.AlignedBlock(directio.BlockSize)
// 把文件数据读到内存块中
_, err := io.ReadFull(fp, buffer)关键在于：buffer 必须是特制的 [ ]byte 数组，而不能仅仅根据 make([ ]byte, 512 ) 这样去创建，因为仅仅是 make 无法保证地址对齐。
总结
- direct io 必须满足 io 大小，偏移，内存 buffer 地址三者都扇区对齐；
- O_DIRECT 不在 os 库，而在于操作系统相关的 syscall 库；
- Go 中无法直接使用 make 来分配对齐内存，一般的做法是分配一块大一点的内存，然后在里面找到对齐的地址即可；
~完～