BqLog这个系列写到这里已经不只谈“快”这个结果了。前两篇我从线程模型和内存分配角度拆过它今天这篇专门讲压缩日志这条执行路径。为什么单把压缩拎出来说因为在真实对局里日志压缩往往是最容易拖垮性能的一环又偏偏是回捞线上问题绕不开的必经之路。BqLog之所以能把压缩藏在幕后还让人感知不到它的存在核心不是用了某个更牛的压缩算法而是把压缩在整条执行路径上的位置、时机、资源都安排明白了。这篇适合已经在做客户端基础库、中间件或者在做性能敏感场景日志系统的同学。不了解BqLog的也不影响阅读我把链路设计和取舍思路讲透你拿去改造自己的日志组件一样成立。1. 日志压缩为什么值得单独做一次路径优化1.1 游戏日志的真实生产环境有多恶劣做游戏客户端日志组件跟做后端日志系统面对的压力是两个维度。后端日志量大但机器资源宽松客户端是资源极度受限还要追帧的场景。一局王者荣耀排位打下来渲染线程、逻辑线程、网络模块、音频模块共同产生日志每秒几千条是非常正常的量级。如果开启战斗内关键节点的详细日志那个量还可以再翻几倍。再加上不少日志带着调用堆栈一条堆栈几十行文本体积瞬间膨胀。日志量大了以后磁盘占用率先扛不住。低端安卓机本身存储空间就紧张日志文件写几个小时就能膨胀到几十上百MB。更难受的是上传。线上问题要靠日志回捞定位一条几十MB的原始日志在用户弱网环境下根本传不回来。所以压缩日志不是“个可选项”而是客户端日志组件在真实环境里活下去的必选项。1.2 压缩日志执行路径上真正的问题是什么压缩本身并不难接一个zlib或LZ4库把日志文本塞进去得到压缩结果写盘完事。丢到主线程以外去做好像就解决了卡顿问题。实际这样做的结果往往是——线程起了内存涨了CPU多了延迟也上去了最终得不偿失只能悄悄把压缩关掉。问题出在“执行路径”这四个字上。一条日志从产生到最终落盘要经过格式化、编码、缓冲、压缩、写盘、上传这么一长串环节。压缩只是其中一环但它会反过来影响前面所有环节的节奏。比如压缩线程和主线程抢CPU比如压缩输出的缓冲区反复申请释放造成内存抖动比如压缩线程把无锁队列的头部拖住导致主线程写入变慢。优化压缩日志不是优化“压缩”这个动作而是优化整条路径的组合方式什么时候压缩、谁触发压缩、压缩结果放在哪、写盘怎么写每一步都影响最终体验。1.3 路径优化的最终衡量标准BqLog对这条路径的要求可以归结为三个指标主线程新增耗时接近零、内存峰值可控、日志吞吐不丢数据。注意这里没提压缩比因为对客户端日志来说压缩比在合适范围内就够了过度追求压缩比反而会吃掉宝贵的CPU。真正的大头是让压缩这条路径不成为业务线程的负担不成为内存增长的帮凶也不在任何峰值时刻掉链子。2. 压缩日志路径的整体结构与设计思路2.1 日志从产生到上传的完整行程先把整条路径画出来。业务线程调用日志接口后日志进入线程局部缓冲格式化并切割成块。块积累了足够数据后被公开成“待压缩”状态压缩线程从无锁队列中取出这些块执行压缩压缩结果进入写盘缓冲。写盘动作由专门的轻量IO逻辑处理按批次顺序写入文件。文件达到体积阈值或者一局结束触发上传任务把压缩日志回传给服务端。这条路径每一步之间的衔接才是优化重点。线程局部缓冲决定了业务线程写日志时本地内存分配受限。无锁队列决定了块从业务线程交到压缩线程时不需要锁竞争。压缩线程的调度时机决定了CPU占用是平缓还是突变。这几个点中任何一处设计粗糙整条路径都会在高压场景下暴露短板。2.2 按块切分为压缩可定位和快速索引打基础块是这条路径上最核心的数据单元。BqLog把日志流按固定大小切块常用的块大小在64KB到128KB之间。切成块有几个直接好处。第一对压缩友好。LZ4这类压缩算法在连续内存上的压缩效率最高按块压缩可以保证输入数据在内存上是连续的减少字节对齐和碎片问题。第二方便定位。线上排查问题时经常只关心某一时间段或者某一场对局的日志如果不切块想提取一段日志就得解压整个文件。切块之后可以按块索引快速定位到相关区域只解压需要的块。第三损坏隔离。一个块损坏了不影响其他块不至于整份日志作废。切块本身没有技术难点但对块的“生命周期管理”是个大学问。块不能每次新建否则高频日志场景下内存分配次数会让你怀疑人生。BqLog在启动时预分配一批块使用过程中靠状态机流转复用用完回到空闲池下一轮继续使用。这套机制在后面章节细讲。2.3 压缩线程用单线程而不是多线程是刻意的选择多线程压缩看似能提高吞吐但在游戏客户端上经常是负优化。移动端CPU核心数虽然不少但可用核心受温控限制一个压缩线程占满一个大核心对游戏主线程和渲染线程都是实打实的压力。如果上多个压缩线程线程切换、锁同步、内存带宽竞争会进一步放大开销而且日志量不是恒定高负载多线程的收益在很多场景根本用不上。BqLog选择了单线程压缩加一个非常克制的调度策略队列里有待压缩的块就压缩一批队列空了线程进入短暂的等待而不是自旋空转。这样在低负载时压缩线程几乎不消耗CPU在高负载时也能把积压的块稳定消化。2.4 压缩算法选LZ4不是因为它压缩率最高如果只看压缩率Zstandard通常比LZ4表现更好gzip也能拿到更小的体积。但在客户端日志场景压缩率只是其中一个因素。移动端CPU资源太宝贵日志组件不能为了把日志缩小几个百分点让用户游戏帧率掉下去。LZ4的优势在于解压和压缩速度极快资源占用小移动端友好。实际数据上文本日志用LZ4一般能压到原来的25%到40%这个比例对上传回捞来说已经非常够用了。考虑到日志内容本身有大量相似重复的文本LZ4的压缩率也不会比Zstd差太多但CPU开销却低了一个量级。选型时永远是“合适”比“最好”更重要这就是典型例子。3. 核心细节解析执行路径上几个关键节点的实操要点3.1 无锁队列的选型与使用边界块从业务线程到压缩线程之间的交接BqLog采用了无锁队列。很多人一听无锁就觉得高性能但无锁队列也有边界条件用错了反而比加锁更糟糕。首先需要区分单生产者单消费者SPSC和多生产者多消费者MPMC场景。如果日志源头收敛到一个线程局部缓冲那核心路径上就是SPSC可以用一个环形的无锁队列性能和稳定性都最好。如果是多线程直接投递块到全局队列那就必须上MPSC队列实现复杂度更高。实操时有一个很隐蔽的陷阱无锁队列在低并发下性能通常不如普通互斥锁队列。因为无锁操作需要原子指令而原子指令在高频访问下并不便宜。BqLog的做法是在业务线程入口设计线程局部缓冲减少跨线程直接交互的频率让无锁队列上流动的是“块”而不是逐条日志控制粒度一上来无锁才真正发挥价值。另外无锁队列的存储节点分配也需要前置规划。队列本身使用固定容量的环形缓冲区生产和消费的位置靠原子变量维护。如果生产速度持续超过消费速度队列满了怎么办这时候宁可让业务线程丢弃日志或者同步等待一下也不能让队列无限增长否则内存迟早被拖垮。BqLog为队列设置了高水位线达到阈值时触发丢弃策略并记录丢弃统计避免一局打到一半内存被日志撑爆。3.2 块状态机把数据结构的每一次流转都算清楚块在BqLog里是有状态的生命体而不是一堆随处复制粘贴的字节流。一个块的生命周期大致经过空闲态、写入态、待压缩态、压缩完成态、落盘完成态最后再回到空闲态。每个状态的切换都有明确触发条件和归属线程。空闲态时块在空闲池里等待业务线程获取。拿到块后就进入写入态业务线程往里面写日志。写入完成或块达到阈值块进入待压缩队列。压缩线程消费后块进入压缩完成态此时块里的原始文本已被压缩结果替换原始内存释放回池中。写盘完成后块的使命结束重新回到空闲池。这个状态机看似简单但实际开发中很容易因为状态判断不严而出问题。比如块还在写入态就被压缩线程拿走比如压缩完成的结果还没有被写盘就把块回收了。BqLog在实现时并没有过度设计复杂的锁来保护状态而是严格规定每个状态只允许一个线程操作交接点通过队列配合原子变量完成让状态切换本身成为天然的同步屏障。这一点对后来想自己实现日志组件的同学是很好的参考状态机不是增加复杂度而是减少跨线程数据竞争的手段。3.3 压缩触发策略合并打包比随到随压更稳定压缩动作的触发时机直接决定CPU消耗的形态。最直观的想法是队列里来了一个块就立刻压缩但这会让CPU占用呈现出频繁的锯齿状波动也增加了不必要的压缩开销。BqLog的做法是达到一定数量的块或者经过一个极短的时间窗口才触发一次批量压缩。这个设计借鉴了网络协议里的Nagle思想通过累积小数据量来摊薄每次处理的开销。实际场景中默认时间窗口设置在几百毫秒量级数量阈值根据块大小动态估算。如果一局内日志量大很快就能凑够一批块压缩频率自然提升日志量小就靠时间窗口兜底保证延迟不会大到影响回捞效率。这样做下来压缩线程的CPU占用曲线变得平滑对游戏主线程帧率的影响降到最低。3.4 紧急日志要跳过高压缩队列走快速通道压缩路径再怎么优化终归有排队和处理延迟。某些日志等不了这个延迟比如崩溃前写入的关键上下文、错误堆栈、严重告警。这些日志一旦被压缩排队拖住设备可能下一秒就冷启动重启了数据直接丢失。BqLog在设计上专门留了一条快速通道紧急日志绕过压缩直接用副本写入独立的紧急日志文件。这个文件不做复杂格式化以最原始的形式顺序追加保证每个字符都尽快落盘。虽然牺牲了一点磁盘空间但换来的是数据可靠性。这个快速通道的代价很低因为紧急日志的量级本身不大对整体压缩路径也没什么影响。这里需要提醒的是紧急日志的写盘即使绕过压缩也不能同步写文件还是要走缓冲加定时flush否则一个崩溃场景下的日志写入反而可能成为性能事故。3.5 压缩结果写盘顺序追加与批量提交压缩完成后的数据要写盘。日志文件的写入有个原则尽量顺序写。顺序写对闪存设备友好对低端安卓机的eMMC尤其明显。如果日志文件被分散写入或者频繁随机写写盘速度会急剧下降拖慢整条路径。BqLog的写盘逻辑维持一个较大的输出缓冲。压缩线程产生的压缩数据先进入这个缓冲达到一定量后一次性追加到文件尾部。这个方式和前面讲的批量压缩形成配合确保写盘次数少、单次写盘数据大。同时写盘动作包装成独立的IO任务由轻量线程执行不在压缩线程内部直接做文件IO。因为文件IO可能会发生偶发性的长时间等待如果压在每个块后续连贯执行会卡住压缩线程的处理节奏。4. 实操过程压缩路径优化的落地步骤与性能验证4.1 从现有日志组件改造为压缩执行路径的操作步骤如果你手头已经有一套日志组件想按BqLog这套思路做压缩路径优化我的建议是按以下顺序递进实施别一上来就全盘推翻重写。第一步先把日志格式化和缓冲做成线程局部隔离。确保业务线程写日志时不需要和其他线程抢锁内存也在线程局部缓存里分配。这一步做不好后面所有优化都会被锁竞争拖住。第二步引入固定大小的块和空闲池。把原来随意增长的日志缓冲区改为按块管理固定块大小建议128KB太小则压缩率上不去太大则空闲池内存占用过高。块从空闲池取出和归还的接口要设计得足够简洁理想情况是只做指针移动不做内存清零。第三步实现SPSC无锁队列连接业务线程和压缩线程。如果业务线程是多处直接写日志的需要先做一层汇聚层把写入操作收敛到一个线程局部入口以“块”为粒度投递。第四步接入压缩库。LZ4的API很简单压缩和获取压缩后大小都有现成函数关键是把压缩处理的输出缓冲纳入内存池管理别用库内部的默认分配。压缩任务的执行放在独立线程按3.3的触发策略批量运行。第五步实现紧急日志快速通道。用独立的缓冲区保存紧急日志第一时间追加写入原始文件避免被压缩流程拖累。第六步做压测。模拟一局对局的日志产生曲线观察主线程新增耗时、内存峰值和日志丢失率。这里需要在高频日志场景下把日志输出量拉满让块的状态流转、无锁队列的水位、压缩线程的调度都经受到极限考验。4.2 一局对局压测下的数据对比这里给一组我在测试环境得到的数据场景设定为对战过程持续15分钟日志峰值每秒5000条每条日志平均长度在300字节左右。比较优化前实时逐条压缩写盘和优化后批量压缩路径的表现。指标优化前优化后说明主线程平均新增耗时约2.1ms/帧约0.2ms/帧批量压缩后主线程只负责写块主线程最大耗时12ms以上1.6ms峰值差异主要来自排队写盘15分钟日志原始体积约180MB约180MB输入量一致压缩后文件体积约52MB约48MB块合并压缩略提升压缩率峰值内存占用动态分配频繁波动大稳定在38MB块池内预分配和复用消除了内存抖动日志丢包率峰值时约1.2%0%队列高水位设计保障需要说明这些数据基于我的测试环境手机上具体数值会因CPU性能和日志内容格式不同而有波动但优化后的趋势是清晰且稳定的主线程开销从毫秒级降到微秒级内存从不可控变为可控丢包不再出现。4.3 上线观测与灰度反馈的重要性压测归压测真正暴露执行路径问题的地方是线上环境。BqLog的优化能在多个版本迭代中持续站稳离不开一套自带的轻量观测埋点。日志组件本身会定期汇报处理日志条数、压缩后字节数、队列水位、丢弃数这些关键指标。这些指标不写进业务日志而是走独立的上报通道避免污染日志数据。灰度阶段把开启压缩路径的版本逐步放量重点盯两个数据一是崩溃率有没有因为日志路径改动而上升二是异常退出时日志文件有没有有效落盘。如果新产品上线后虽然一般路径性能好看但关键时刻日志反而没保存下来那整个优化就是失败的。观测一定要覆盖正常路径和紧急路径两边两边都不能失守。5. 常见问题与排查技巧实录5.1 压缩后对象膨胀块回收没有及时归还空闲池这是我自己踩过的一个坑。压缩线程完成压缩后原始块的内存应该立刻归还空闲池。如果反馈不及时或者状态判断失误空闲池里的块越来越少组件只能被迫新建块内存占用就不断增长最终表现为日志组件内存越用越大。排查方式很简单在观测指标里增加空闲池当前块数如果在长时间运行时持续下降说明块回收链路上有泄漏或者归还延迟。常见的坑是原始块内存压缩完了之后被某个局部变量拽着引用GC不回收导致块状态始终停在压缩完成态。写C的朋友尤其要注意块回收的逻辑要跟着状态机走不能依赖调用端自觉。5.2 CPU占用曲线锯齿状波动压缩时机触发策略不对如果你发现压缩线程的CPU占用忽高忽低呈现明显尖峰排查思路先看触发策略。如果是随到随压一定会形成锯齿如果是攒批然后突发压缩也会因为批量和阈值设置不合理形成峰谷。理想状态是一段时间内CPU占用保持平缓说明压缩速率和日志产生速率匹配。调整方向把数量触发阈值调低一点让压缩线程更频繁但每次处理更少数据或者把时间窗口拉长让日志积累得更多再进行压缩。关键是要让压缩操作的频率和数据的到达频率达到一个动态平衡避免压一下停一下。5.3 无锁队列消费者饥饿导致业务线程背压无锁队列生产端是业务线程消费端是压缩线程。如果压缩线程因为其他任务繁忙得不到调度队列就可能长时间处于高位业务线程写入受阻日志组件反过来拖累游戏帧率。这个问题的表象在主线程但根因在压缩线程的调度。解决办法是给压缩线程设置合适的优先级并且在队列高水位时适当让压缩线程加速消费。但必须注意压缩线程再急也不能抢占主线程的CPU时间片日志组件永远不能反噬业务的实时性。因此这里需要在调度策略上做取舍优先保证主线程稳定即使丢掉一部分非关键日志也不要让日志线程拖慢游戏逻辑。5.4 内存碎片导致压缩线程偶发卡顿日志组件高频分配小块内存长时间运行后内存碎片会越来越严重。偶发性的分配延迟可能让压缩线程在某一次分配上卡了很久。这个问题的根因在分配策略而不是压缩本身。BqLog的解法是尽量禁用直接堆分配通过固定槽位的内存池管理所有缓冲区。实践下来内存池自身的实现和维护成本并不高但对长期运行稳定性的提升非常可观。5.5 真机发热与耗电上升压缩带来的CPU压力如何收敛如果优化后打一局手机发热明显先别怀疑压缩算法去查日志量是不是比预估大了很多倍。某些上线活动会增加详情日志日志量暴涨后压缩线程被迫更频繁地工作CPU占用自然上升。这时与其优化压缩算法不如先做日志分级把debug级日志在正式包关闭把低频问题定位日志而保留核心链路日志。日志量降下来CPU和内存压力都会随之缓解。另外要谨防压缩线程在设备空闲时过度工作。一局打完了队列里可能还有不少积压块。BqLog的做法是严格控制后台补压的量不让日志组件长时间占着CPU去做优先级不高的压缩任务。说到底日志组件的使命是服务开发者定位问题而不是取代用户的游戏体验。最后分享一个执行路径优化里最容易忽略的小技巧到这篇为止BqLog的“快”算是拆得比较透了。最后我想单独提一个细节也是一个极易被忽略的点压测量测工具本身也会改写执行路径。如果你在日志组件里插桩统计耗时插桩本身会改变指令执行时间结果可能失真。更隐蔽的是如果你用打印方式观察队列水位打印操作本身会消耗时间等于变相降低了日志产生速度压测结果自然就“好看”了。我常用的做法是只统计计数不打印明细用原子变量累加关键指标另开一条独立旁路定期快照。这样观测过程与业务线程完全隔离测出来的数字才接近真实。日志组件是个“隐形的工程”它的好坏很难直接感受到但往往在最关键的那一次线上事故排查时你才会意识到——这组件当时优化得值不值。BqLog的这套压缩路径优化就是我亲身验证过“值”的案例。