从0手写一个多线程日志包( 二 ) _日志包

经过以上梳理，整个日志包在设计思路上变得清晰了起来，即：
1) 在内存中创建两个缓冲区，缓冲区大小视日志量和频率大小而定，通常取4k左右。
2) 当前端模块往第一块缓冲区写入内容时，后端模块则将第二块缓冲区的内容写入到文件。
3) 当第一块缓冲区写满时，则交换顺序，前端往第二块缓冲区写入内容，而后端则将第一块缓冲区内容写入到文件。

文章插图
图片
图3 前台模块写入第一块缓冲区，后台模块将第二块缓冲区内容写入到文件

文章插图
图片
图4 前台模块写入第二块缓冲区，后台模块将第一块缓冲区内容写入到文件
当然，仅仅这样还不足以作为成熟而高效的日志包，在缓冲区的设计上还需考虑写入文件的实时性，即当缓冲区一直写不满时需在固定的时间进行缓冲区的强制切换，以保证日志文件中能读取到较为实时的日志内容。
在一些日志文件处理细节问题上，如程序突然退出时截获系统信号，尽可能将剩余日志内容写入到文件以便后续跟踪问题等;在不借助第三方工具状态下，使用两级文件指针的方式，保证按固定时间分割的日志不会出现日志消失等情况。
在日志包对外暴露的方法上，同大多数日志包一样，提供分级的日志打印方式，并设计模板变量以支持任意格式的日志内容，同时还提供输出格式方法以及日志文件分割方法以便进行便利的日志包配置。
在综合考虑这些问题后，整个流程如下：

文章插图
图片
图5 整体流程图
Part 05 总结以上便是日志包的主要设计思路，从这样的设计思路中我们可以看到，整个设计上主要就是如何对抗以下两个核心问题：
第一个是应程序中多线程的资源抢占问题，第二个便是计算机磁盘的低效率问题。
该日志包已经在移动On.NET公有云平台、城市物联网平台等平台里面发光发热，体量最大的公有云平台日均处理日志量已超过4亿条。当然，在日志包这一模块过后，如果还需补充完整整个日志系统，后续的日志采集、日志落库、日志分析等又是一个有一个新的技术探索领域。

【从0手写一个多线程日志包】