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

Part 01 引言

可能大家会想，现在各种编程语言里面都有着各种各样的日志处理函数，比如JAVA里面不仅仅可以通过System.out.print()方法打印日志，还有log4j等更为成熟的专业日志包可以进行调用;不仅仅Java，php、Golang、Python/ target=_blank class=infotextkey>Python等当前互联网行业用的比较多的编程语言都提供了成熟的日志方法类或者日志包，甚至上古编程语言C++也提供了简易的日志方法。那么读者朋友们有兴趣知道类似log4j这样的日志包其底层到底是如何构建高效率的日志处理方法吗?亦或是未来遇到了这些日志包已经无法满足需求了，必须要自己写高度定制化日志服务才能较好地处理等场景的时候。俗话说，技多不压身，接下来，本文将从0开始探讨和分析如何写一个高可用的日志包。

Part 02 模型概述

通常来说，软件应用的日志分为两个部分：前端部分以及后端部分，其中针对前端部分主要是开发者的应用程序通过程序逻辑构造需要打印的日志内容，再通过调用日志打印方法进行日志的打印。而后端则是像背后看不见的英雄一样，主要负责把这些内容实实在在地写到既定的地方。

这样的分工让我们不自觉地便能套用上“生产者-消费者”数据模型。这种模型想必只要是计算机圈子的同学都不会陌生：各种经典的数据队列应用如kafka、RocketMQ等，其中的用户手册中第一章必然会说说“生产者”和“消费者”两者的关系。那么套用到本文日志模型里面，前端部分作为构建日志内容并调用日志方法的模块，则能套用上“生产者”这一概念，而后端真正的日志处理部分则套用上“消费者”这一概念。

图片

图1 生产者和消费者关系图

Part 03 问题分析

通常来讲，计算机世界绝大多数应用都采用了多线程处理的方式，以此来高效率地服务计算机使用者们，多线程就类似于买卖东西的窗口，多一个窗口就能在同一时间多服务一个客户。我们先假设这些服务窗口都属于上个世纪的形态，未进行信息化升级，所有的服务流水、服务内容等都记录在纸上，那么窗口管理人员怎么来汇总这些信息呢?这个倒不是什么难题，聪明的读者们也一定能想到：在下班后统一收集放在一起就可以了。如果要保证时间顺序呢?也不难，按所有窗口纸张上记录的服务时间排序再誊抄一份就可以了。那么终极问题来了，如果还要保证实时性呢?那要不再加派一人，只要某个窗口完成了客人的服务，则马上去该窗口收集实时的信息，然后交给后面的人立即誊抄汇总。

而本质上多线程的日志问题和窗口信息传递问题基本一致，日志最终是落入计算机磁盘存储，而日志所对应的文件则属于进程独占模式——同一个文件只能在一个时间里被一个进程使用，如果不设成进程独占的方式，可以对应想象上一段落所说的窗口汇总表，如果多个誊抄人同时在那张纸上写来写去会怎样?

图片

图2 多线程日志整体关系图

Part 04 日志包设计

多线程并发的目标是提升整体性能，但是应用程序采用了多线程的方式则会相应地引入线程间上下文切换、内存同步、贤臣阻塞等问题。而简单处理这种问题的方式则是对线程进行加锁。其实在很多时候，并发编程提升性能优化应用能力方面主要就是围绕如何优化线程的锁，一些方法论主要讲述如何缩小锁的范围、减少锁的粒度、锁分段、避免热点区域加串行锁等进行展开，围绕这些方法论也诞生了读写锁、分段锁等方法。单独针对日志文件采用读写锁是比较合理的手段，即只在写入的时候对文件进行加锁，读取的时候所有应用都可以任意读取文件获取内容，这样既保证了写入文件内容的原子性也保证了其他业务能获取日志的实时性。

解决了文件读取的问题，那么在写入日志文件的时候直接粗暴地加锁会不会对整个应用的性能造成重大影响呢?答案是肯定的，这样做的结果就是整个应用性能瓶颈都集中到了计算机磁盘性能上，很显然，计算机的磁盘性能可不咋地。针对此，在日志包的设计上又想到了“生产者-消费者”模型中的数据通道，简单来说，这块主要通过缓冲区来实现，在常用的日志包设计上，多数都采用“双缓冲区”的方式作为日志包的核心。

经过以上梳理，整个日志包在设计思路上变得清晰了起来，即：

1) 在内存中创建两个缓冲区，缓冲区大小视日志量和频率大小而定，通常取4k左右。

2) 当前端模块往第一块缓冲区写入内容时，后端模块则将第二块缓冲区的内容写入到文件。

3) 当第一块缓冲区写满时，则交换顺序，前端往第二块缓冲区写入内容，而后端则将第一块缓冲区内容写入到文件。

图片

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

图片

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

当然，仅仅这样还不足以作为成熟而高效的日志包，在缓冲区的设计上还需考虑写入文件的实时性，即当缓冲区一直写不满时需在固定的时间进行缓冲区的强制切换，以保证日志文件中能读取到较为实时的日志内容。

在一些日志文件处理细节问题上，如程序突然退出时截获系统信号，尽可能将剩余日志内容写入到文件以便后续跟踪问题等;在不借助第三方工具状态下，使用两级文件指针的方式，保证按固定时间分割的日志不会出现日志消失等情况。

在日志包对外暴露的方法上，同大多数日志包一样，提供分级的日志打印方式，并设计模板变量以支持任意格式的日志内容，同时还提供输出格式方法以及日志文件分割方法以便进行便利的日志包配置。

在综合考虑这些问题后，整个流程如下：

图片

图5 整体流程图

Part 05 总结

以上便是日志包的主要设计思路，从这样的设计思路中我们可以看到，整个设计上主要就是如何对抗以下两个核心问题：

第一个是应程序中多线程的资源抢占问题，第二个便是计算机磁盘的低效率问题。

该日志包已经在移动On.NET公有云平台、城市物联网平台等平台里面发光发热，体量最大的公有云平台日均处理日志量已超过4亿条。当然，在日志包这一模块过后，如果还需补充完整整个日志系统，后续的日志采集、日志落库、日志分析等又是一个有一个新的技术探索领域。