Mudo C++网络库第五章学习笔记

高效的多线程日志

日志(logging)有两个意思:
- 诊断日志(diagnostic log), 常用日志库提供日志功能;
- 交易日志(transaction log), 用于记录状态变更, 通过回放日志可以逐步恢复每一次修改后的状态;
日志通常用于故障诊断和追踪(trace), 也可用于性能分析;
日志通常是分布式系统中事故调查时的唯一线索, 用来追寻蛛丝马迹, 查出原凶;
- Log Everything All The Time;
关于进程, 日志通常要记录:
- 收到每条内部消息的ID(还可以包括关键字段、长度、hash等);
- 收到的每条外部消息的全文;
- 发出每条消息的全文, 每条消息都有全局唯一的id；
- 关键内部状态的变更, 等等;
每条日志都有时间戳, 这样就能完整追踪分布式系统中一个事件的来龙去脉;
一个日志文件可分为前端(frontend)和后端(backend)两部分;
- 前端提供应用程序使用的接口(API), 并生成日志消息(log message);
- 后端则负责把日志消息写到目的地(destination);
- 典型的多生产者-单消费者问题, 对生产者(前端)而言, 要尽量做到低延迟、低CPU开销、无阻塞;
- 对消费者(后端)而言, 要做到足够大的吞吐量, 并占用较少资源;
对C++程序而言, 最好整个程序(包括主程序和程序库)都使用相同的日志库, 日志有一个整体的日志输出, 而且不要各个组件有各自的日志输出;
- 从这个意义上讲, 日志库是个singleton模式(单例模式);
muduo没有用标准库中的iostream, 而是自己写的LogStream class, 主要是出于性能原因;

功能需求

日志消息有多种级别(level): TRACE、DEBUG、INFO、ERROR、FATAL等;
日志消息可能有多个目的地(appender), 如文件、socket、SMTP等;
日志消息的格式可配置(layout), 例如org.apache.log4j.PatternLayout;
可以设置运行时过滤器(filter), 控制不同组件的日志消息的级别和目的地;
质量保证(QA)测试环境的时候输出DEBUG级别的日志, 在生产环境输出INFO级别的日志;
只要调用muduo::Logger::setLogLevel()就能立即生效;
对于分布式系统中的服务进程而言, 日志的目的第(destination)只有一个:本地文件;
- 日志文件的滚动(rolling)是必需的, 这样可以简化日志归档(archive)的实现;
rolling的条件通常有两个: 文件大小(例如每写满1GB就换下一个文件)和时间(例如每天零点新建一个日志文件, 不论前一个文件有没有写满);
- 一般的日志库都会自动根据文件大小和时间来主动滚动日志文件;
- 能主动rolling, 自然也就不必支持SIGUSR1了, 毕竟多线程程序处理signal很麻烦;
日志库的压缩与归档(archive)不是日志库应该有的功能, 而应该交给专门的脚本去做;
磁盘空间监控也不是日志库的必备功能;
muduo日志库: 其一是定期(默认3秒), 将缓冲区内的日志消息flush到磁盘;
- 其二是每条内存中的日志消息都带有cookie(或者叫哨兵值/sentry), 其值为某个函数的地址, 这样通过core dump文件中查找cookie就能找到尚未来得及写入磁盘的消息;
日志消息格式有几个要点:
- 尽量每条日志占一行;
- 时间戳精确到微妙;
- 始终使用GMT时区(Z);
- 答应线程id;
- 打印日志级别;
- 打印源文件名和行号;

性能需求

日志库的高效性体现在几个方面:
- 每秒写上千万条日志的时候没有明显的性能损失;
- 能应对一个进程生产大量日志数据的场景, 例如1GB/min;
- 不阻塞正常的执行流程;
- 在多程序程序中, 不造成争用(contention);
- 磁盘带宽约是110MB/S, 日志库应该能瞬时写满这个带宽(不必持续太久);
- 假如每条日志消息的平均长度是110字节, 这就意味着1秒要写100万条日志;
muduo日志库实现了几点优化措施:
- 时间戳字符串中的日期和时间部分是缓存的, 一秒内的多条日志只需要重新格式化微妙部分;
- 日志消息的前4个字段是定长的, 因此可以避免在运行期求字符串长度(不会反复调用strlen);
  - 因为编译器认识memcpy()函数, 对于定长的内存复制, 会在编译期把它的inline展开为高效的目标代码;
- 线程id是预先格式化为字符串, 在输出日志消息时只需要简单拷贝几个字节;
- 每行日志消息的源文件名部分采用了编译期计算来获得basename, 避免运行期strrchr()开销;

多线程异步日志

多线程程序对日志库提出了新的需求:线程安全, 即多个程序可以并发写日志, 两个线程的日志消息不会出现交织;
多线程的每个进程最好只写一个日志文件;
- 用一个背景线程收集日志消息, 并写入日志文件, 其他业务线程只管往这个日志线程发送日志消息, 这称为异步日志;
- 非阻塞日志;
我们需要一个队列将日志前端的数据传送到后端(日志线程)；
- muduo日志库采用的是双缓冲(double buffering)技术;
- 基本思路是准备两块buffer：A和B, 前端负责往buffer A填数据(日志消息), 后端负责将buffer B的数据写入文件;
- 当buffer A写满之后, 交换A和B, 让后端将buffer A的数据写入文件, 而前端则往buffer B填入新的日志消息, 如此往复;
- 为了及时将日志消息写入文件, 即便buffer A未满, 日志库也会每3秒执行一次上述交换写入操作;
对于异步日志来说, 这是典型的生产速度高于消费速度问题, 会造成数据在内存中的堆积, 严重时引发性能问题(可用内存不足)或程序崩溃(分配内存失败);
- 直接丢弃掉多余的日志buffer, 以腾出内存, 这样可以防止程序库本身引起程序故障, 是一种自我保护措施;
- 也可以加入网络报警功能, 通知人工介入, 以尽快修复故障;
性能不能凭感觉说了算, 一定要有典型场景的测试数据做为支撑;
muduo库的异步日志实现用了一个全局锁;
- java的ConcurrentHashMap那样用多个桶子(bucket), 前端写日志的时候再按线程id哈希到不同的bucket中, 以减少contention(后端实现比较复杂);
- Linux默认会把core dump写到当前目录, 而且文件名是固定的core;