Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > Go存储direct io

Go存储基础使用direct io方法实例

作者：qiya

这篇文章主要介绍了Go存储基础之如何使用direct io方法实例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

Go 存储编程怎么使用 O_DIRECT 模式？

今天分享一个存储细节，Go 存储编程怎么使用 O_DIRECT 模式？

之前提过很多次，操作系统的 IO 过文件系统的时候，默认是会使用到 page cache，并且采用的是 write back 的方式，系统异步刷盘的。由于是异步的，如果在数据还未刷盘之前，掉电的话就会导致数据丢失。

如果想要明确数据写到磁盘有两种方式：要么就每次写完主动 sync 一把，要么就使用 direct io 的方式，指明每一笔 io 数据都要写到磁盘才返回。

那么在 Go 里面怎么使用 direct io 呢？

有同学可能会说，那还不简单，open 文件的时候 flag 用 O_DIRECT 嘛，然后。。。

是吗？有这么简单吗？

提两个问题，童鞋们可以先思考下：

O_DIRECT 的知识点

在此之前，先回顾 O_DIRECT 相关的知识。direct io 也就是常说的 DIO，是在 Open 的时候通过 flag 来指定 O_DIRECT 参数，之后的数据的 write/read 都是绕过 page cache，直接和磁盘操作，从而避免了掉电丢数据的尴尬局面，同时也让应用层可以自己决定内存的使用（避免不必要的 cache 消耗）。

direct io 一般解决两个问题：

direct io 模式需要用户保证对齐规则，否则 IO 会报错，有 3 个需要对齐的规则：

思考标题

为什么 Go 的 O_DIRECT 知识点值得一提？

以下按照两层意思分析思考。

第一层意思：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)

第二层意思：Go 无法精确控制内存分配地址

标准库或者内置函数没有提供让你分配对齐内存的函数。

direct io 必须要满足 3 种对齐规则：io 偏移扇区对齐，长度扇区对齐，内存 buffer 地址扇区对齐。前两个还比较好满足，但是分配的内存地址作为一个小程序员无法精确控制。

先对比回忆下 c 语言，libc 库是调用 posix_memalign 直接分配出符合要求的内存块。go 里面怎么做？

先问个问题：Go 里面怎么分配 buffer 内存？

io 的 buffer 其实就是字节数组嘛，很好回答，最常见自然是用 make 来分配，如下：

buffer := make([]byte, 4096)

那这个地址是对齐的吗？

答案是：不确定。

那怎么才能获取到对齐的地址呢？

划重点：方法很简单，就是先分配一个比预期要大的内存块，然后在这个内存块里找对齐位置。 这是一个任何语言皆通用的方法，在 Go 里也是可用的。

什么意思？

比如，我现在需要一个 4096 大小的内存块，要求地址按照 512 对齐，可以这样做：

以上就是基本原理了，童鞋理解了不？下面看下代码怎么写。

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 。

我太懒了，一行代码都不愿多写，有开源的库吗？

还真有，推荐个：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 无法保证地址对齐。

总结

以上就是Go存储基础使用direct io方法实例的详细内容，更多关于Go存储direct io 的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:
阅读全文