背景

我们总有这样的担忧：总有刁民想害朕，总有人偷偷在目录下删改文件，高危操作想第一时间了解，怎么办？ 而且通常我们还有这样的需求：

• 监听一个目录中所有文件，文件大小到一定阀值，则处理；
• 监控某个目录，当有文件新增，立马处理；
• 监控某个目录或文件，当有文件被修改或者删除，立马能感知，进行处理；

怎么解决呢？通常来说有三个办法：

• 第一种：当事人主动通知你，这是侵入式的，需要当事人修改这部分代码来支持，依赖于当事人的自觉；(ps.显然这不太可能）
• 第二种：轮询观察，这个是无侵入式的，你可以自己写个轮询程序，每隔一段时间唤醒一次，对文件和目录做各种判断，从而得到这个目录的变化；（每次轮询累不累？不实时、不直观）
• 第三种：操作系统支持，以事件的方式通知到订阅这个事件的用户，达到及时处理的目的；

很显然第三种相对来说是最好的，具体怎么操作呢？

• 既然是操作系统的支持，那么就应该用到系统调用。系统调用直接使用略微复杂了些，Golang显然已经有了支持，使用fsnotify库就可以轻松实现这个功能。
• fsnotify库就是封装了系统调用，用来监控文件事件的。当指定目录或者文件，发生了创建，删除，修改，重命名的事件，里面就能得到通知。

Golang 的 fsnotify 的使用

• 使用方法非常简单：
  • 先用 fsnotify 创建一个监听器；
  • 然后放到一个单独的 goroutine 监听事件即可，通过 channel 的方式 或者 启动新的 goroutine 进行事件传递；

package main

import (
	"github.com/fsnotify/fsnotify"
	log "github.com/sirupsen/logrus"
)

func TestFileMonitor() {
	// 创建文件/目录监听器
	watcher, err := fsnotify.NewWatcher()
	if err != nil {
		log.Fatal("watcher new err: [%+v]", err)
		return
	}
	defer watcher.Close()
	done := make(chan bool)
	go func() {
		for {
			select {
			case event, ok := <-watcher.Events:
				if !ok {
					return
				}
				// 打印监听事件
				log.Print("event:", event)
				// 可以启动新的goroutine或使用channel进行事件传递
			case _, ok := <-watcher.Errors:
				if !ok {
					return
				}
			}
		}
	}()
	// 监听当前目录
	err = watcher.Add("./")
	if err != nil {
		log.Fatal("err add dir: [%+v]", err)
	}
	<-done
}

我们来测试一下，先把上述程序编译，然后跑起来：

然后我们来创建一个文件：

使用 vim 打开这个文件，写入一行数据，然后关闭退出：
最终运行结果：

深层原理

fsnotify 是跨平台的实现，这里只讲 Linux 平台的实现机制。fsnotify 本质上就是对系统能力的一个浅层封装，主要封装了操作系统提供的两个机制：

• inotify 机制
• epoll 机制

内核版本：Linux 4.15.0-76-generic

1、inotify 机制

• 这是一个内核用于通知用户空间程序文件系统变化的机制。
• 划重点：其实 inotify 机制的诞生源于一个通用的需求，由于IO/硬件管理都在内核，但用户态是有获悉内核事件的强烈需求，比如磁盘的热插拔、文件的增删改等操作。这里就诞生了三个异曲同工的机制：hotplug 机制、udev 管理机制、inotify 机制。
• inotify 的三个接口：

// fs/notify/inotify/inotify_user.c
// 创建 notify fd
inotify_init1()
// 添加监控路径
inotify_add_watch()
// 删除一个监控
inotify_rm_watch()

// 用法非常简单，分别对应 inotify fd 的创建，监控的添加和删除。

1.1 inotify 怎么实现监控的？

• inotify 支持监听的事件非常多，除了增删改，还有访问、移动、打开、关闭、设备卸载等等事件。
• 内核要上报这些文件 api 事件必然要采集这些事件，它们在哪一个内核层次采集的呢？

系统调用 -> vfs -> 具体文件系统（ ext4 ）-> 块层 -> scsi 层
（当然是 vfs 层，这是必然的，因为这是所有“文件”操作的入口。
）

• 以 vfs 的 read/write 为例，我们看一下具体实现：

ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
    // ...
    ret = __vfs_read(file, buf, count, pos);
    if (ret > 0) {
        // 事件采集点：访问事件
        fsnotify_access(file);
    }

}

ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
{
    // ...
    ret = __vfs_write(file, buf, count, pos);
    if (ret > 0) {
        // 事件采集点：修改事件
        fsnotify_modify(file);
    }
}

• fsnotify_access 和 fsnotify_modify 就是 inotify 机制的一员。有一系列 fsnotify_xxx 的函数，定义在 include/linux/fsnotify.h ，这函数里面全都调用到 fsnotify 这个函数。

static inline void fsnotify_modify(struct file *file)
{
    // 获取到 inode

    if (!(file->f_mode & FMODE_NONOTIFY)) {
        fsnotify_parent(path, NULL, mask);
        // 采集事件，通知到指定结构
        fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0);
    }
}

• 我们简单的梳理一下 fsnotify 函数实现的调用栈：

fsnotify
    -> send_to_group
        -> inotify_handle_event
            -> fsnotify_add_event
                -> wake_up （唤醒等待队列，也就是 epoll）

• 再看一个具体的实现（其实非常简单，就是一个事件通知）：

// 把事件通知到相应的 group 上；
int fsnotify(struct inode *to_tell, __u32 mask, const void *data, int data_is, const unsigned char *file_name, u32 cookie)
{
        // ...
        // 把事件通知给正在监听的 fsnotify_group
        while (fsnotify_iter_select_report_types(&iter_info)) {
                ret = send_to_group(to_tell, mask, data, data_is, cookie, file_name, &iter_info);
                if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
                        goto out;
                fsnotify_iter_next(&iter_info);
        }
out:
        return ret;
}

static int send_to_group(struct inode *to_tell, __u32 mask, const void *data, int data_is, u32 cookie, const unsigned char *file_name, struct fsnotify_iter_info *iter_info)
{
    // 通知相应的 group ，有事来了！
    return group->ops->handle_event(group, to_tell, mask, data, data_is, file_name, cookie, iter_info);
}

// group->ops->handle_event 被赋值为 inotify_handle_event

int inotify_handle_event(struct fsnotify_group *group, struct inode *inode, u32 mask, const void *data, int data_type, const unsigned char *file_name, u32 cookie, struct fsnotify_iter_info *iter_info)
{
    // 唤醒事件，通知相应的 group
    ret = fsnotify_add_event(group, fsn_event, inotify_merge);
}


// 添加事件到 group 
int fsnotify_add_event(struct fsnotify_group *group, struct fsnotify_event *event, int (*merge)(struct list_head *, struct fsnotify_event *))
{
    // 唤醒这个等待队列
    wake_up(&group->notification_waitq);
}

• 这里面的逻辑非常简单：把这次的事件通知给关注的 fsnotify_group 结构体，换句话说，就是把事件通知给 inotify fd。
• 这个就有意思了，inotify fd 句柄创建的时候，file->private_data 上就绑定了一个 fsnotify_group ，这样的话，针对文件的所有操作，都能有一份事件发送到 fsnotify_group 上，inotify fd 就有可读事件了。

1.2 其实 inotify 也有支持 epoll 机制

• 在前面我们也提到了，Golang 的 fsnotify 主要使用了两个系统机制： inotify 和 epoll。fsnotify 则把 inotify fd 放到 epoll 池里面管理。
• 换句话说，inotify fd 也同样支持 epoll 机制。有最明显的两个特征：
  • inotify fd 的 inotify_fops 实现了 poll 接口；
  • inotify fd 相关的某个结构体一定有个 wait 队列的表头；
    • 啥结构体？这个结构体就是 fsnotify_group 。被存放在 inotify fd 对应的 file->private_data 字段。这个 wait 队列表头就是 group->notification_waitq 。

来看一眼结构体的简要关系：

2、epoll 机制

• 回到 Golang 的 fsnotify 库的实现原理，fsnotify 利用的第二个系统机制就是 epoll 。inotify fd 通过 inotify_init1 创建出来之后，会把 inotify fd 注册进 epoll 管理，监听 inotify fd 的可读事件。

2.1 inotify fd 的可读事件能是啥？

• 其实就是它监听的文件或者路径发生的增删改的事件，这些事件就是内核 inotify 报上来的
• 报上来之后，epoll 监控到 inotify fd 可读，用户通过 read 调用，把 inotify fd 里面的“数据”读出来。这个读出来的所谓的“数据”就是一个个文件事件

我们看一眼整体的模块层次：

总结

• Golang 的 fsnotify 库很方便对文件、目录做监控，这里的充满了想象力，因为一切皆文件，这代表着一切可监控。童鞋们，这里的想象空间非常大哦；
• 通过 fsnotify 我们映证了 vim 的秘密；
• Golang 的 fsnotify 其实操作系统能力的浅层封装，Linux 本质就是对 inotify 机制；
• inotify 也是一个特殊句柄，属于匿名句柄之一，这个句柄用于文件的事件监控；
• fsnotify 用 epoll 机制对 inotify fd 的可读事件进行监控，实现 IO 多路复用的事件通知机制；