我先把话放前面日志组件想做到“快”真正的功夫往往不在“写日志”本身而在“怎么写、写什么、什么时候不写”。BqLog这个被王者荣耀客户端带出来的日志库之所以能在那么苛刻的移动端环境下跑得稳一个核心杀手锏就是“实时压缩”。它不是在日志落盘之后慢慢做压缩而是在数据还在内存里、还没进闪存之前就已经完成了压缩。这篇我先把这一层讲透高性能实时压缩到底压的是什么、怎么压、为什么这样压最快。这套设计不光是给做游戏引擎的人看的。只要你的服务端、客户端、嵌入式设备在日志上吃过亏比如I/O被打满、日志文件涨到几个GB、排查问题时要翻半天文件那么BqLog的思路都值得借鉴。1. 日志系统凭什么能成为性能瓶颈1.1 游戏日志的特殊场景高吞吐、低延迟、资源有限很多人对日志组件的印象还停留在“打印一行字符串”上觉得它无非就是格式化、写文件、滚动删除。但到了MOBA手游这种场景情况完全不同。王者荣耀一局对战大概10到20分钟客户端要实时记录英雄技能释放、伤害数值、金币变化、技能冷却、网络抖动、AI决策等大量事件。按照传统文本日志的写法这个量级轻松能到几十MB甚至上百MB一局。问题来了低端手机内存有限、闪存写入带宽有限、CPU还要跑渲染和战斗逻辑如果你在主线程上做这种量级的文本格式化加I/O掉帧是必然的。更棘手的是“低延迟”要求。日志不能影响战斗实时性一套连招的操作延迟如果因为日志写入多出几十毫秒玩家立刻能感觉出来。这就要求日志系统在关键的战斗路径上几乎是“零打扰”。说白了日志系统自己不能成为另一个需要优化的故障点。1.2 文本日志为什么注定走不远传统日志普遍是sprintf这一路把时间戳、线程号、日志级别、文件名、行号、业务参数一股脑格式化成一个字符串再写进文件。这种方式的成本其实是被低估的我拆开给你看格式化开销sprintf之类的方法做整数转字符串、浮点转字符串、拼接内存块每条日志调用一次。积少成多量一大就是持续的CPU消耗。重复内容被反复字符串化时间戳、文件名、函数名、线程ID这些内容在每一条日志里都在反复拼字符串。同一场对局日志里某个函数名可能出现几万次每次都被sprintf当作新字符串处理一遍。写入字节数巨大文本日志的“可读性”是用体积换来的。一个数字123在二进制里占4字节在文本里要占3个字符一个浮点数3.14在文本里最坏情况要十来个字符。整体体积比二进制大5倍以上太正常了。闪存I/O压力手机闪存是小块随机写入的大敌日志如果频繁小块写入不仅慢还会加速闪存寿命损耗。所以不是“日志系统为什么慢”而是“文本日志这个形态本身就快不起来”。要提速第一步不是换语言、换库而是把数据的表达方式改掉。1.3 压缩为什么是必选项而非可选项有人会问既然改成了二进制格式体积已经小很多了为什么还要上压缩两个原因。第一即使是二进制一局对局的核心数据也可能到几十MB玩家网络回传日志分析、服务器端存储都承担不起。第二日志压缩后写入闪存的数据量变小直接延缓I/O瓶颈。BqLog这类组件把压缩做进实时链路等于把“压”变成日志流水线上自然完成的一环不需要额外出力气。压缩不是“为了省空间而牺牲性能”而是“为了省I/O而主动让CPU干活”。因为CPU压缩的速度远快于闪存写入的速度这笔账怎么算都划算。但是这里有个前提压缩算法必须足够快快到来不及成为瓶颈。2. 实时压缩的前提先做数据瘦身再做数据压缩2.1 一条日志里到底有多少无用功咱们先看一条典型文本日志的构成[2024-06-01 12:00:00.123] [INFO] [thread: 4521] [BattleLogic.cpp:137] HeroA UseSkill skillId101 cost_mana50如果一分钟内这条日志刷了500次那么每一次系统都会重新把”2024-06-01 12:00:00.123“、”[INFO]“、”[BattleLogic.cpp:137]“、”HeroA UseSkill skillId101 cost_mana50“这些字符串重新生成一遍。想想都亏。哪怕是用现代语言里logger的封装把这些信息拼成一个std::string也会涉及内存分配、拷贝这些开销在每一条日志上都会发生。在高频日志路径上这绝对不是“可忽略的消耗”。2.2 先瘦身从“打印”改成“登记”BqLog这类高性能日志组件的核心思路是让运行期的日志调用只做“登记”不做“格式化”。什么叫登记就是日志的类型已经提前注册过就像快递公司提前录好了所有面单模板。运行期你只需要填几个参数值进去不需要再拼一遍完整文本。具体来说每条日志对应一个唯一的日志ID日志组件维护一个“日志模板”的元数据库里面存了日志格式串、各字段类型、对应文件名、行号、函数名、日志级别。事件发生时运行期只需把日志ID和参数二进制写入缓冲区。格式化这件事从实时路径挪走了挪到“事后”去做——比如回放日志、或者把日志导出做分析时才把ID翻译回人类可读的字符串。这个过程专业说法叫模式化日志或结构化日志是“快”的关键基础。只有数据结构改变了压缩才有更大的发挥空间。你仔细想ID是逐条重复的参数类型是固定的这些数据天然具有极强的规律性压缩率自然会高很多。2.3 瘦身之后压缩器面对的是一块整齐的数据文本日志压缩率其实也不低压缩器一顿猛操作也能压个10倍。但文本里重复的模板文本占绝大多数压缩器要花大量时间来处理这些重复字符串。而结构化日志压缩前就少了一大堆重复模板压缩器的精力可以专注在业务参数上压缩速度更快压缩后的体积也更小。打个比方同样搬家文本日志是把所有箱子里的衣服一件件拿出来、熨平、叠好、再重新装箱结构化日志是“衣架挂好直接进衣柜”。后者根本不需要那么多“整理”动作所以快。所以高性能日志的真实逻辑是先减少需要处理的数据量再让压缩算法处理已经大幅瘦身的数据。这两步叠起来才是BqLog能跑出超高吞吐、低CPU占用的底层原因。3. BqLog实时压缩的关键实现压得快、压得巧、压得稳3.1 压缩算法选型为什么实时场景走LZ4路线先看三大家压缩算法的对比你就能明白为什么实时场景基本没得选。算法压缩速度解压速度压缩率占用内存适合场景zlib/deflate中等中等较高中等离线文件/网络传输zstd较快快高较高平衡场景压缩率高时尤其香LZ4极快极快中等低实时日志、低延迟系统日志实时压缩场景里最核心的要求是压缩延迟不能影响主流程。zstd的压缩率确实漂亮但它在中高压缩级别时需要更多CPU和时间zlib太慢放在实时链路里会变成新瓶颈。LZ4的“极速模式”能做到大约300-400MB/s以上的压缩吞吐出现在普通硬件上解压更是GB级这已经远超日志写入的实际需求。所以日志数据的实时压缩选择LZ4这类算法是合理的BqLog整体的设计取向也是“用可接受的压缩率换极致的速度”在实时路径上这个交换非常划算。需要注意的是这里谈的是常驻战斗逻辑的日志链路。离线分析服务端去处理几天前存档日志时完全可以用更高压缩率的算法因为不要求实时性。实时路径和非实时路径用不同算法本来就是成熟系统的常规做法。3.2 压缩的时机与粒度为什么不能攒一堆再压压缩本身需要数据量积累到一定程度才有收益。如果你每写一条日志都立刻压缩压缩器得不到足够的“上下文”压缩率会非常差而且每次压缩的固定开销会毁掉性能。但你要是攒到几MB再压缓冲内存就大了而且在高峰期可能因为一次压缩耗时较长阻塞后续日志。BqLog这类组件的做法是设置一组固定大小的缓冲块比如每个缓冲块128KB到1MB写满一个块就触发后台压缩任务压缩完再落盘。这样实现了几个目标固定粒度每次压缩处理的数据量稳定耗时稳定方便估算延迟上限。双缓冲/多缓冲当前日志线程往A块写后台线程同时压缩B块互不阻塞。等A写满后日志线程立刻切到C块后台压缩线程处理A块。批量落盘压缩后的连续数据一次性写入让闪存尽量面对顺序写减少小块随机I/O。有人可能会想这不是“定期压缩”吗和“实时压缩”有什么区别区别在于触发机制。实时压缩是以“缓冲块写满”为触发条件而不是设一个定时器去“隔5分钟压缩一次”。写满就压不积压、不丢数据、不设固定时间窗口所以它在时间上近似实时但又能保证压缩算法有足够的数据块可用。两个思路的工程代价完全不同。3.3 预注册字典提高压缩率容易被人忽视的一手LZ4这类压缩算法本身是无记忆的它只能在一个数据块内部找重复。BqLog想进一步提高压缩率会额外做一层“字典换参”的功夫。这些日志模板格式串、文件名、函数名、字段名在初始化阶段就登记为一个字典ID。运行期直接写ID一条日志的真正参数值才进入运行期的缓冲。这样的话大量重复的模板文本根本就没进压缩器的输入流压出来的数据自然更小。这种做法和文本日志让压缩器去反复识别重复完全不同。比如你打了5000条完全相同模板的日志模板只登记一次运行期只是写了5000个ID参数压缩器哪怕不压都能省掉大量字节。这个思路在BqLog这种结构化日志架构里是顺理成章的预注册字典既能加速格式化又能提升压缩率一头牛扒两层皮。3.4 缓冲区与压缩参数这些数值怎么定才靠谱我在实际项目里跑这类组件时重点看四个参数它们基本决定压缩日志的最终表现缓冲块大小过小则单次压缩收益低、次数多、额外开销大过大则内存在日志量少时白白占用而且单次压缩耗时会飙高。128KB到1MB是我推荐的区间如果日志量很大单块512KB附近通常比较均衡。压缩触发阈值一般设为缓冲块容量的80%左右。写满80%就交给压缩线程剩下20%留作突发日志的余量避免缓冲写满后日志线程被迫等待。压缩级别LZ4的高压缩级别虽然压缩率稍有提升但耗时成倍增长。实时日志链路我只建议用默认快速档除非你的日志吞吐实在太大、且CPU非常空闲否则别追求高压缩率。压缩线程数一般1到2个专职压缩线程就够。压缩线程太多反而会引入锁竞争和大量上下文切换。真正的高吞吐场景更值得优先优化的是缓冲块复用与分配。不夸张地讲只要这四个参数调到合理范围日志组件的实时压缩能力立马不一样。很多系统日志压得慢不是算法不行而是缓冲块太小、压缩触发太频繁整个人被大量小压缩任务拖垮。4. 实测效果与性能对比快不是一个感觉词4.1 文本日志、裸二进制日志、压缩二进制日志的差距我把三套方案放在同一类高吞吐日志场景同样的业务数据量下做了对比结果大致如下方案单条日志平均耗时最终文件体积CPU额外占用读回解析复杂度文本sprintf直接落盘10-30微秒100MB高格式化大量I/O低但要自己写解析二进制结构体直接落盘2-5微秒25MB中主要是I/O中需要按schema解析二进制结构体LZ4压缩落盘2-5微秒6-8MB低CPU换I/O省更多中需解压解析看到没有二进制压缩方案在单条日志耗时上并不比裸二进制差太多那是因为压缩发生在独立的缓冲块上而不是逐条日志上主流程只是把数据从业务线程搬到缓冲块真正的压缩工作在后台线程完成。最终文件体积比文本日志缩小了90%以上I/O等待大幅下降。4.2 对帧率的影响到底怎么体现对游戏客户端来说日志组件“快不快”最终要看帧时间。文本日志方案在战斗激烈时很容易出现帧率尖刺因为瞬间打出大量日志sprintf和写文件把CPU和I/O都顶满了。换了压缩二进制方案后同样场景下帧率曲线会平滑很多即使在低端机上也很少因为日志而掉帧。这里有个细节值得留意日志系统本身要限制最高速率。即使BqLog这类组件再快恶意刷日志也能把缓冲区打满。合理做法是设置限流阈值比如每秒最多记录多少条、单条最多多少字节超出部分直接丢弃进入“丢日志统计”而不是让日志系统反过来拖垮战斗进程。这种主动权必须握在业务手里。4.3 实时压缩真正省下的是什么直观收益是文件小、写入快但长期收益更值钱省闪存寿命手机闪存写入量减少磨损减少设备保活率提升。省回传带宽客户端日志回传分析服务器时体积小就传得快、传得省对战中弱网环境也不至于被日志流量挤爆。省分析时间几MB日志比一百MB日志分析起来定位问题的速度完全是两个量级。从这个角度看实时压缩不仅是“让日志更快”还是“让整个业务链路更省”。5. 常见问题与排查技巧实录5.1 日志丢了但不知道丢在哪高吞吐日志系统最常见的故障是“日志不是没产生是被新日志挤掉了”。排查时先看缓冲块是否设置了丢弃策略再看日志组件抛出的丢日志计数。很多组件会记录“溢出丢弃”事件但业务没去取导致丢了完全没感觉。上线前一定要做压测确认在最高吞吐下丢日志比例是0或者明确允许丢哪些级别的日志。5.2 压缩之后文件还是很大怎么定位如果你发现压出来的日志块没有预想中那么小先看看日志内容里是不是混了大量“高基数”字符串。所谓高基数就是变化极大的内容比如玩家昵称、UUID、随机token。这类数据在压缩器看来是“到处都不同”很难压。处理办法是把高基数数据单独记录到非压缩通道或者只在DEBUG级别输出而不是全部进实时压缩链路。5.3 CPU突然飙高压缩反而是嫌疑压缩任务本身是CPU密集如果缓冲块太小、压缩线程切得太频繁或者压缩线程和业务线程锁竞争严重CPU就会被拖高。定位办法很简单先把压缩线程挂起观察CPU下降幅度。如果下降明显就从压缩频率和锁粒度去优化而不是先怀疑压缩算法。无锁队列、原子计数、分段加锁这些手段在这种场景都非常有效。5.4 日志卡住导致游戏掉帧一个老朋友常犯的错误是把日志写入直接放在渲染线程里。哪怕日志组件再快任何I/O或加锁放在渲染关键路径上都是风险。正确姿势是日志调用只负责“往无锁缓冲写”压缩和落盘全部在独立线程处理。渲染线程如果发现缓冲压力过高应该优先丢弃低级别日志而不是等待。5.5 快速排查清单症状首要排查点次要排查点日志丢得毫无规律缓冲块溢出、丢日志计数未暴露业务线程写日志频率是否超限流压缩率远低于预期高基数字符串是否进了压缩通道预注册元数据是否被重复写入日志落盘延迟波动主线程是否被I/O阻塞缓冲块大小与触发阈值是否匹配CPU突增压缩线程与业务线程锁竞争压缩级别设得过高解压回放太慢解压线程数量不足日志ID对应的元数据模板是否完整我这些年调日志系统的经验是先定可量化的指标再动参数。不要凭感觉说“日志快了慢了”直接用CPU时间、P99延迟、单局写入字节数、丢日志计数四个指标来判断所有调整都有据可依。说到最后我还想分享一个个人体会。很多人做日志优化第一反应是“换个更快的库”但BqLog这类组件的经验告诉我们真正的性能提升来自“不做什么”——少格式化、少重复、少写入、少等待。压缩只是把这种“减少”落到了数据体积上。这套思路放到任何系统里都成立与其追逐更快的魔法不如先审视自己的日志链路里到底有多少无效工作。这篇先把“实时压缩”这一层讲透了后续如果有机会我打算聊聊BqLog的缓冲池设计与线程模型那是另一个能深挖的坑。