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 来分配对齐内存，一般的做法是分配一块大一点的内存，然后在里面找到对齐的地址即可；
4546
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
