1. 从一条日志的旅程说起为什么压缩日志的执行路径值得单独优化很多人第一次接触 BqLog是因为它在高频战斗场景下依然能把日志写入的抖动压到极低。但真正让这套组件在同类方案里拉开差距的不是能压缩这件事本身而是压缩日志执行路径被拆得足够细、足够短。我最早做性能剖析时也走过弯路以为瓶颈在磁盘 IO结果火焰图一拉发现大量时间耗在了压缩前的数据搬运和校验环节上。这个认知转变是理解 BqLog 为什么快的起点。先把场景说清楚。所谓压缩日志指的是日志在写入落盘之前先在内存里做一次批量压缩把多条日志记录合并成一个压缩块再写出。这样做的好处很直接同样的日志量磁盘写入次数大幅减少IO 压力下降长期存储成本也跟着降。但代价是压缩本身要消耗 CPU而且压缩前的数据组织、校验、边界处理都会引入额外开销。如果这些环节设计得不好压缩省下来的 IO 时间会被 CPU 开销吃掉甚至倒亏。BqLog 的思路是既然压缩不可避免那就把执行路径做到极致精简。所谓执行路径就是从一条日志产生到进入压缩器之间代码实际要走过的所有分支、函数调用、内存操作。路径越短、分支越少、缓存越友好单位日志的处理成本就越低。这篇文章就围绕这条路径把 BqLog 在压缩日志场景下的优化思路、关键细节、实操要点和踩坑经验完整拆一遍。适合谁看如果你正在做高吞吐日志组件、嵌入式埋点、游戏战斗日志或者单纯对高性能 C 组件怎么抠细节感兴趣这篇都能给你一些可以直接抄作业的东西。我会尽量把每个设计选择背后的为什么讲透而不是只丢结论。2. 压缩日志执行路径的整体设计与取舍逻辑2.1 为什么要把压缩和执行路径分开看很多人把压缩日志当成一个整体功能来优化上来就换压缩算法、调压缩级别。我试过收益有限。原因是压缩算法只占整条路径的一部分真正拖后腿的往往是压缩之前的那段准备逻辑。BqLog 把这条路径拆成几个清晰的阶段日志记录生成、暂存区写入、批量聚合、校验计算、压缩编码、落盘。每个阶段都有独立的开销优化时必须分开度量。这么拆的好处是你能清楚知道每一纳秒花在哪。比如校验计算如果放在压缩之后做就要对整个压缩块算一次如果放在压缩之前对原始数据算虽然数据量大但可以和写入暂存区合并做反而更快。这种取舍只有把路径拆开才能看清楚。2.2 核心设计目标短路径、少分支、缓存友好BqLog 在这条路径上的三个核心目标我总结成一句话让 CPU 尽量做顺序的、可预测的、贴着缓存走的事情。短路径减少函数调用层级能内联的内联避免为了代码好看而引入抽象层。日志这种热路径一次虚函数调用的开销在百万级 QPS 下会被放大到不可忽视。少分支分支预测失败是性能杀手。路径上的条件判断要尽量可预测比如把是否达到压缩阈值这种判断做成大概率走同一条分支。缓存友好日志数据在内存里的布局要连续避免指针跳转。压缩器读数据时最好是顺序读这样预取器能发挥作用。这三个目标不是孤立的它们互相牵制。比如为了少分支你可能要牺牲一点内存为了缓存友好你可能要放弃某些灵活的数据结构。BqLog 的选择是优先保证热路径的确定性把复杂性推到冷路径或者初始化阶段。2.3 与常见方案的对比为什么不用现成的日志库加压缩市面上不少日志库的做法是日志先格式化成字符串写进一个缓冲区缓冲区满了再整体压缩。这个方案实现简单但有两个问题。第一字符串格式化本身开销大尤其是数字转字符串第二压缩器面对的是已经格式化的文本压缩率不如面对结构化二进制数据。BqLog 走的是另一条路日志在内存里保持结构化或半结构化的紧凑表示压缩器直接吃这种紧凑数据。这样既省了格式化开销又提高了压缩率。代价是压缩器和日志格式耦合更紧扩展性差一些。但对于追求极致性能的场景这个取舍是值得的。方案格式化开销压缩率路径长度扩展性文本缓冲后压缩高中长好结构化紧凑表示后压缩低高短一般不压缩直接写无无最短好这张表不是要证明谁绝对好而是说明 BqLog 的选择是在特定目标下的最优解。如果你的场景日志量不大、对延迟不敏感用现成方案完全没问题。3. 核心细节解析校验、哈希与数据组织的关键取舍3.1 CRC 校验放在路径的哪个位置最划算CRC 校验是压缩日志里绕不开的一环用来保证压缩块在落盘和读取时的完整性。但 CRC 放在哪直接影响路径长度。常见有三种放法每条日志记录单独算 CRC写入时逐条校验。整个压缩块算一次 CRC落盘前算读取时校验。压缩前对原始数据算 CRC压缩后不再算。BqLog 选的是第二种为主、第一种为辅的混合策略。原因是逐条算 CRC 会让热路径变长每条日志都要走一遍 CRC 计算循环而整块算一次虽然单次计算量大但可以放在压缩之后、落盘之前的相对冷的阶段不阻塞日志生成。至于为什么还要保留逐条校验作为辅助是为了在调试模式下快速定位是哪条日志损坏生产环境则关闭逐条校验。这里有个容易踩的坑CRC 校验码计算的多项式选择。不是随便一个多项式都能用。业界有个共识某些多项式无法保证检出全部奇数个比特错误这类多项式不能作为 CRC 生成多项式。选型时一定要用经过验证的标准多项式比如 CRC-32 常用的那个。自己拍脑袋定一个多项式测试时可能碰巧没问题上线后遇到特定错误模式就漏检了。3.2 哈希在路径中扮演的角色不只是查重哈希在 BqLog 的压缩路径里有两个用途。一是日志模板去重相同格式的日志只存一份模板记录里只存参数二是压缩字典的快速查找压缩器需要快速判断某个片段是否出现过。模板去重这个设计很关键。战斗日志里大量记录格式相同、只有数值不同比如玩家 X 对玩家 Y 造成 Z 点伤害。如果每条都完整存压缩率上不去。用哈希把模板映射成 ID记录里只存模板 ID 加参数数据量能降一个数量级。但哈希表本身有开销。每次日志生成都要查一次哈希表如果哈希函数慢或者冲突多热路径就被拖长了。BqLog 的做法是用一个固定大小的开放寻址哈希表哈希函数选的是计算极快的位运算混合冲突用线性探测。这样查表基本是一次内存访问缓存命中率高。提示哈希表大小要提前根据模板数量预估。太小冲突多太大浪费缓存。我一般按预估模板数的 1.5 到 2 倍来定并且用 2 的幂次方便做位运算取模。3.3 数据在内存里的布局连续比聪明更重要压缩器读数据的速度很大程度上取决于数据在内存里是否连续。BqLog 的暂存区是一块预分配的大缓冲区日志记录按顺序追加不做链表、不做树。这样压缩器可以顺序扫描CPU 预取器能提前把数据拉进缓存。我见过一些实现用链表串日志记录每条记录单独分配。这种布局在压缩时就是灾难指针跳来跳去缓存命中率极低。BqLog 坚决避免这种设计宁可牺牲一点灵活性也要保证内存连续。具体做法是暂存区按固定块大小分配比如 64KB 一块。日志记录追加到当前块块满了就切下一块。压缩时按块处理块内数据连续压缩器读起来很顺。块大小也不是随便定的64KB 大致能覆盖 L2 缓存的一部分既不会太大导致缓存失效也不会太小导致频繁切换。4. 实操过程从日志生成到压缩落盘的完整路径4.1 日志记录生成阶段的精简写法先看日志生成。这一步的目标是尽快把一条日志变成紧凑的字节序列追加到暂存区。核心原则是避免任何不必要的分配和格式化。// 简化示意非 BqLog 原始代码 struct LogRecord { uint32_t templateId; // 模板哈希 ID uint16_t paramCount; uint8_t paramTypes[MAX_PARAMS]; uint64_t paramValues[MAX_PARAMS]; }; inline void appendLog(uint32_t templateId, const uint64_t* params, uint16_t count) { // 直接在当前块尾部构造不做堆分配 LogRecord* rec reinterpret_castLogRecord*(currentBlock-tail); rec-templateId templateId; rec-paramCount count; for (uint16_t i 0; i count; i) { rec-paramValues[i] params[i]; } currentBlock-tail sizeof(LogRecord); if (currentBlock-tail currentBlock-end) { rotateBlock(); // 切块大概率分支 } }这段代码有几个细节值得说。第一参数用固定大小的数组而不是变长容器避免动态分配。第二rotateBlock的判断是大概率不触发的分支分支预测器能很好处理。第三整个追加过程没有函数调用开销appendLog会被内联。参数类型这里我简化了实际实现里会用变体或者类型标记来支持不同类型。但核心思想不变用固定布局换速度。4.2 批量聚合与压缩触发时机的选择暂存区攒够一定量之后就要触发压缩。触发时机很讲究。触发太频繁压缩器启动开销占比高触发太晚内存占用大延迟抖动也大。BqLog 用的是双阈值策略块数达到阈值 A 触发压缩或者距离上次压缩超过时间 T 也触发。阈值 A 保证吞吐时间 T 保证延迟上限。两个条件哪个先满足走哪个。bool shouldCompress() { return pendingBlocks COMPRESS_BLOCK_THRESHOLD || (now() - lastCompressTime) COMPRESS_INTERVAL_MS; }COMPRESS_BLOCK_THRESHOLD这个值需要根据实际压测调。我一般从 8 块开始试观察压缩线程的 CPU 占用和日志延迟分布再微调。太小了压缩线程忙不过来太大了内存涨得快。4.3 压缩前的数据整理与 CRC 计算压缩前要把待压缩的块整理成压缩器能吃的连续输入。如果块本身连续这一步几乎零开销如果块之间有间隙就要先拷贝合并。BqLog 通过块分配策略保证块之间尽量连续减少拷贝。CRC 计算放在这一步。对整个待压缩数据算一次 CRC结果存在压缩块头部。uint32_t crc crc32(data, totalSize); compressBlockHeader.crc crc; compressBlockHeader.rawSize totalSize;CRC 计算本身可以用查表法加速预生成 256 项的表每次处理一个字节查一次表。现代 CPU 上还可以用硬件指令加速但为了可移植性BqLog 默认用查表法检测到硬件支持时切换到硬件实现。注意CRC 表要在初始化阶段生成好不要放在热路径里算。我见过有人在每次压缩时重新生成表白白浪费几毫秒。4.4 压缩编码与落盘压缩算法选型上BqLog 没有用通用压缩库而是针对日志数据特点做了定制。日志数据的特点是重复模式多、数值局部性好所以用了基于字典的轻量压缩配合简单的熵编码。压缩级别可调默认级别在压缩率和速度之间取平衡。落盘用异步 IO压缩线程把压缩块交给 IO 线程就返回不阻塞。IO 线程负责实际的写操作和错误处理。这样压缩和 IO 可以并行整体吞吐更高。void compressAndSubmit() { auto data gatherPendingBlocks(); uint32_t crc crc32(data.data(), data.size()); auto compressed compressor.compress(data); compressed.header.crc crc; ioThread.submit(std::move(compressed)); // 异步提交 }整个路径到这里结束。从日志生成到落盘热路径上只有追加、判断、偶尔的切块压缩和 IO 都在相对冷的阶段完成。5. 常见问题与排查技巧实录5.1 压缩后日志读取校验失败怎么排查这是最常见的问题。读取时 CRC 校验失败说明数据在写入或存储过程中损坏。排查顺序建议这样先确认是不是 CRC 计算范围不一致。写入时算的范围和读取时算的范围必须完全一样差一个字节都会失败。检查压缩块头部是否被覆盖。有时候缓冲区越界会踩到头部。确认存储介质没问题。偶发的校验失败可能是磁盘坏道。如果只在特定数据上失败检查压缩器是否有边界 bug。我踩过一次坑压缩块头部和压缩数据共用一个缓冲区压缩器写数据时越界了一个字节把头部的 CRC 字段覆盖了。这种问题很难查最后是靠加边界检查断言定位的。5.2 哈希冲突导致日志模板错乱哈希冲突如果处理不当两条不同的日志模板可能映射到同一个 ID导致读取时模板对不上。开放寻址法要保证探测序列正确删除操作要特别小心不能简单置空否则会打断探测链。排查方法在调试模式下记录每个模板的原始字符串读取时对比。如果发现模板内容对不上就是冲突处理有问题。解决方法是增大哈希表或者换更好的哈希函数。5.3 压缩线程 CPU 占用过高如果压缩线程持续跑满一个核说明压缩触发太频繁或者压缩级别太高。先看触发阈值把COMPRESS_BLOCK_THRESHOLD调大试试。如果还高降低压缩级别。日志场景下压缩率差几个百分点通常可以接受换来的 CPU 节省更值。5.4 常见问题速查表现象可能原因排查方向解决思路读取 CRC 失败计算范围不一致、缓冲区越界、介质损坏对比写入读取范围、加边界断言统一范围、修复越界、换介质模板错乱哈希冲突处理不当调试模式对比模板原文增大哈希表、换哈希函数压缩线程 CPU 高触发频繁、级别过高看触发阈值和级别配置调大阈值、降级别日志延迟抖动大压缩阻塞了写入路径检查压缩是否异步确保压缩和 IO 异步内存增长快触发太晚、块回收不及时看 pending 块数调小阈值、及时回收5.5 几个我踩过的坑第一个坑是 CRC 多项式选错。早期我用了一个自己定义的多项式测试数据上没问题后来遇到一种特定的位翻转模式CRC 没检出来。查了资料才知道某些多项式无法保证检出全部奇数个比特错误这类多项式不能作为 CRC 生成多项式。换成标准多项式后问题消失。第二个坑是哈希表在扩容时阻塞了热路径。早期实现里哈希表满了会触发扩容扩容要重新哈希所有条目耗时较长正好发生在日志高峰期导致明显卡顿。后来改成预分配足够大的表并且扩容放到独立的维护线程做热路径只读不写。第三个坑是压缩块大小定得太大。一开始用 1MB 一块想着减少块切换开销。结果压缩时单块处理时间长延迟抖动明显。改成 64KB 后抖动小了很多吞吐几乎没降。6. 路径优化的度量方法与调优经验6.1 怎么度量执行路径的开销优化不能靠感觉要有数据。BqLog 在调试模式下会统计每个阶段的耗时日志生成、暂存追加、CRC 计算、压缩、落盘。这些统计用轻量的计数器实现生产环境可以关闭。度量时要注意统计本身也有开销。我一般用采样而不是全量统计比如每 1000 条日志统计一次减少对热路径的干扰。火焰图是另一个好工具。把日志高峰期的火焰图拉出来看热路径上哪些函数占的时间多。我最初就是靠火焰图发现 CRC 计算占比比预期高才决定把它挪到压缩之后。6.2 调优的优先级顺序调优要有优先级不要眉毛胡子一把抓。我的经验顺序是先消除热路径上的动态分配。这是收益最大的一步。再优化内存布局保证连续。然后减少分支把可预测的判断前置。最后才考虑压缩算法本身的调优。很多人一上来就调压缩算法其实前面几步的收益往往更大。压缩算法调优的边际收益递减很快而消除一次动态分配可能直接省下几微秒。6.3 不同负载下的参数调整参数没有万能值要根据负载调。低负载场景压缩阈值可以调小让日志尽快落盘减少内存占用。高负载场景阈值调大让压缩批量更大提高压缩率减少 IO 次数。我一般会准备几套预设参数根据运行时的日志速率自动切换。速率低时用低延迟预设速率高时用高吞吐预设。切换逻辑放在维护线程不影响热路径。提示参数调整后一定要用真实负载压测不要只看微基准。微基准和真实场景的差异可能很大尤其是缓存行为和分支预测。7. 写在最后的一点个人体会这套压缩日志执行路径的优化我前后迭代了挺多版本。最大的体会是性能优化不是找一个大招而是把一堆小事情做对。CRC 放对位置、哈希表预分配、内存布局连续、分支可预测每一条单独看都不起眼但叠在一起就是数量级的差距。另外度量永远比直觉可靠。我很多次以为瓶颈在某处一测发现完全不是。火焰图和分阶段计时是必备工具没有数据支撑的优化都是瞎猜。最后分享一个小技巧如果你也在做类似的日志组件建议在早期就把调试模式的逐条校验和统计做进去。生产环境关掉但开发和压测阶段开着能帮你快速定位问题。等出了问题再补这些设施成本高得多。