日志文件系统

对文件系统进行修改时，需要进行很多操作。这些操作可能中途被打断，也就是说，这些操作不是“不可中断”(atomic)的。如果操作被打断，就可能造成文件系统出现不一致的状态。

例如：删除文件时，先要从目录树中移除文件的标示，然后收回文件占用的空间。如果在这两步之间操作被打断，文件占用的空间就无法收回。文件系统认为它是被占用的，但实际上目录树中已经找不到使用它的文件了。

在非日志文件系统中，要检查并修复类似的错误必须对整个文件系统的数据结构进行检查。这个操作可能会花费很长的时间。

为了避免这样的错误，日志文件系统分配了一个称为日志的区域来提前记录要对文件系统做的更改。在崩溃后，只要读取日志重新执行未完成的操作，文件系统就可以恢复一致。这种恢复是原子的，因为只存在几种情况：

• 不需要重新执行：这个事务被标记为已经完成
• 成功重新执行：根据日志，这个事务被重新执行
• 无法重新执行：这个事务会被撤销，就如同这个事务没有发生过一样
• 日志本身不完整：事务还没有被完全写入日志，他会被简单忽略

日志系统的设计

为什么需要日志

对于一些高频操作（如心跳包、定时器、界面绘制下的某些高频重复的行为），可能在少量次数下无法触发我们想要的行为，而通过断点的暂停方式，我们不得不重复操作几十次、上百次甚至更多，这样排查问题效率是非常低下的。对于这类操作，我们可以通过打印日志，将当时的程序行为上下文现场记录下来，然后从日志系统中找出某次不正常行为的上下文信息。

日志系统的技术上的实现

同步写日志

所谓同步写日志，指的是在输出日志的地方，将日志即时写入到文件中去。采用这种方式，势必造成CPU等待，进而导致主线程“卡”在写文件处，进而造成界面卡帧。

但是，很多时候我们不用担心这种问题，主要有两个原因：其一，是用户感觉不到这种同步写文件造成的延迟；其二，是客户端除了UI线程外，还有其他与界面无关的工作线程，在这些线程中写文件一般不会对用户的体验产生什么影响。

多线程同步写日志出现的问题一——不同线程的日志事件时间序列错乱

产生这种问题的主要原因是由于多个线程同时写日志到同一个文件时，产生日志的时间和实际写入磁盘的时间不是一个原子操作。我们可以这样来理解，一个线程T1在t1时刻产生了日志，另一个线程T2在t2时刻也产生了一个日志（t2 > t1）。但是由于一些原因导致线程T1发生阻塞，并没有把日志即刻写入到文件中，而线程T2并没有发生阻塞，即刻就把日志信息写入到了文件中。这种情况的存在就会导致不同线程的日志事件时间序列错乱。

多线程同步写日志出现的问题二——不同线程的日志输出错乱拼接

假设线程A的日志信息为AAAAAA，线程B的日志信息为BBBBBB，线程C的日志信息为CCCCCC。那么会不会产生一种情况使得日志文件中的输出结果为AABBCCAABBCCAABBCC。

实际上，在类Unix系统上（包括Linux），同一个进程内针对同一个FIEL*的操作是线程安全的，也就是说在Linux系统上不会产生上述的情况发生。

在Windows系统上，由于对FILE*的操作并不是线程安全的，可能会发生上述情况。

这种同步日志的实现方式，一般用于低频写日志的软件系统中，所以可以认为这种多线程同时写日志到同一个文件中是可行的。

异步写日志

所谓异步写日志，就是通过一些线程同步技术将日志先暂存下来，然后再通过一个或多个专门的日志写入线程将这些缓存的日志写入到磁盘中。

实现的时候可以使用一个队列来存储其他线程产生的日志，日志线程从该队列中取出日志，然后将日志内容写入文件。