1. 从一次日志写入卡顿说起BqLog 的性能瓶颈到底藏在哪如果你做过移动端游戏的性能优化大概率遇到过这种场景战斗最激烈的时候帧率突然从 60 掉到 40抓了半天 CPU Profiler发现耗时不在渲染、不在逻辑而是集中在一个你平时根本不会注意的模块——日志。王者荣耀这种级别的项目线上日志量是极其恐怖的一场团战下来技能释放、伤害结算、网络同步、AI 行为树每个环节都在打日志。如果日志组件本身不够快它就会从辅助工具变成性能杀手。BqLog 就是在这个背景下被反复打磨出来的一套日志组件。上一篇文章我们聊了它在整体架构上的取舍这一篇重点拆两个东西环形队列和自适应数据总线。这两个词听起来像是两个独立的技术点但实际用下来你会发现它们是咬合在一起的——环形队列解决的是写入端不能阻塞的问题自适应数据总线解决的是消费端怎么跟得上生产端的问题。少了任何一个整套方案都跑不起来。我先说一个很多人容易误解的点日志组件的快不是指单条日志写入的绝对耗时有多低而是指在高并发、高吞吐场景下它不会成为业务线程的拖累。这两者是完全不同的优化目标。前者你可以靠各种奇技淫巧把单次调用压到几十纳秒但一旦并发上来锁竞争、内存分配、缓存失效会把你打回原形。BqLog 的设计思路从一开始就是冲着后者去的所以它的核心结构才会落到环形队列上。这篇文章适合谁看如果你正在自研日志组件、正在做移动端性能优化、或者单纯对无锁队列和生产者消费者模型感兴趣那接下来的内容应该能给你一些可以直接抄作业的思路。我会尽量把每个设计决策背后的为什么讲清楚而不是只丢一堆结论。2. 环形队列为什么成了写入端的第一选择2.1 从数组 q[m] 存放循环队列元素说起先把这个最基础的结构讲透。所谓环形队列本质就是一块固定大小的连续内存用两个游标来标记读写位置。假设我们用数组q[m]来存放循环队列中的元素同时用rear和length分别指示队尾位置和当前元素个数那么整个队列的状态就可以用这两个变量完整描述出来。// 环形队列的核心状态 #define QUEUE_SIZE (1 16) // 65536必须是 2 的幂 typedef struct { LogEntry buffer[QUEUE_SIZE]; volatile uint32_t rear; // 写游标 volatile uint32_t length; // 当前元素数量 } RingQueue;为什么用rear加length而不是传统的head加tail这是个很实际的工程选择。用head/tail组合时判断队空和队满需要额外条件要么牺牲一个槽位要么额外维护一个标志位而用rearlength的组合队空就是length 0队满就是length QUEUE_SIZE判断逻辑干净利落分支预测也友好。在日志这种每秒可能写入几十万条的场景下少一个分支就是实打实的性能收益。写入的时候rear自增并对QUEUE_SIZE取模length加一读取的时候从(rear - length QUEUE_SIZE) % QUEUE_SIZE的位置取数据length减一。取模这个操作在QUEUE_SIZE是 2 的幂时可以直接用位与 (QUEUE_SIZE - 1)替代省掉一次除法。这个细节看起来微不足道但在热路径上除法指令的延迟是位与的十几倍。2.2 固定内存带来的确定性没有 malloc 就没有抖动环形队列最大的价值其实不在于环形这个形状而在于内存是预分配的。日志写入路径上最怕的是什么是malloc。你在业务线程里调一次malloc背后可能是几十到几百纳秒的分配开销更可怕的是它可能触发内存整理、可能加锁、可能因为碎片化导致延迟不可预测。在游戏这种对帧时间极度敏感的场景里一次不可预测的延迟抖动就可能导致掉帧。BqLog 的做法是启动时一次性把环形队列的内存全部申请好之后所有日志写入都只是往这块内存里填数据不做任何动态分配。这就把写入路径的延迟从不可预测变成了基本恒定。我实测过在队列未满的情况下单次写入的耗时稳定在几十纳秒量级而且方差极小。这种确定性比平均耗时低更重要。提示环形队列的大小选择是个权衡。太小了容易满满了就得走降级逻辑太大了占用内存而且缓存局部性会变差。经验值是根据峰值日志速率乘以你能容忍的缓冲时长来定一般留 2 到 4 倍的余量。2.3 无锁写入CAS 与内存序的取舍有了固定内存下一步就是解决并发写入的问题。多个业务线程同时往队列里写怎么保证不冲突最朴素的做法是加锁但锁在竞争激烈时会导致线程挂起和上下文切换这恰恰是我们要避免的。BqLog 采用的是无锁方案核心是原子操作。写入端用 CASCompare-And-Swap来抢占写位置bool try_enqueue(RingQueue* q, const LogEntry* entry) { uint32_t current_rear; do { current_rear q-rear; if (q-length QUEUE_SIZE) { return false; // 队列满走降级 } } while (!__atomic_compare_exchange_n( q-rear, current_rear, (current_rear 1) (QUEUE_SIZE - 1), false, __ATOMIC_ACQ_REL, __ATOMIC_ACQUIRE)); q-buffer[current_rear] *entry; __atomic_fetch_add(q-length, 1, __ATOMIC_RELEASE); return true; }这里有几个关键点值得展开。第一CAS 失败会重试所以写入路径上其实是有循环的但在实际负载下冲突概率很低重试次数通常是个位数。第二内存序的选择很讲究rear的更新用ACQ_REL保证写入位置对其他线程可见length的更新用RELEASE保证数据先写入、计数后更新避免消费者读到还没写完的数据。我踩过的一个坑是早期版本为了图省事把所有原子操作都用SEQ_CST顺序一致性结果在 ARM 平台上性能明显不如 x86。后来改成按需指定内存序ARM 上的写入吞吐提升了将近 30%。这个教训是——内存序不是越强越好够用就行但前提是你得真正理解每个操作之间的依赖关系。3. 自适应数据总线消费端怎么追上生产端3.1 生产快、消费慢这个矛盾绕不开环形队列解决了写入端的问题但紧接着就带来一个新矛盾生产端写入速度可能远高于消费端落盘、上报、格式化的处理速度。如果消费端跟不上队列很快就会满然后写入端只能降级——要么丢日志要么阻塞业务线程。这两种结果都不理想。传统的做法是给消费端开多个线程或者加大队列容量但这都是静态方案应对不了负载的动态变化。战斗场景日志量暴涨主城挂机日志量骤降你不可能按峰值去配置消费资源那样平时就是浪费。BqLog 的自适应数据总线就是冲着这个动态平衡去的。所谓数据总线你可以理解成一条连接生产端和消费端的管道它负责把环形队列里的日志搬运到最终的输出目标文件、网络、控制台等。而自适应体现在这条管道的宽度并发度、搬运策略批量大小、刷新频率会根据当前的队列水位动态调整。3.2 水位驱动的动态调节机制自适应数据总线的核心是一个基于队列水位的反馈回路。系统持续监控length / QUEUE_SIZE这个比值也就是队列的填充率然后根据填充率的高低来调整消费策略。水位区间状态判定消费策略调整0% - 30%空闲降低刷新频率增大批量间隔减少 CPU 占用30% - 70%正常维持基准消费速率批量大小适中70% - 90%繁忙提高消费线程唤醒频率缩小批量间隔90% - 100%告急启用备用消费线程最大化吞吐必要时触发降级这个表格看起来简单但落地时有几个细节决定成败。首先是水位采样的频率——采太勤了本身就有开销采太疏了反应不及时。BqLog 用的是指数移动平均来平滑水位读数避免因为瞬时抖动导致策略频繁切换。其次是策略切换要有迟滞hysteresis比如从繁忙降回正常的阈值要比从正常升到繁忙的阈值低一些防止在边界上反复横跳。我个人的经验是自适应机制最怕的就是震荡。早期版本没有加迟滞结果在某个水位临界点上消费线程一会儿开一会儿关反而比固定策略还慢。后来加了双阈值和冷却时间才稳定下来。3.3 批量聚合把零散写入攒成大块输出消费端另一个关键优化是批量聚合。如果每来一条日志就写一次文件系统调用write的开销会占掉大部分时间。BqLog 的做法是让消费端一次从环形队列里取一批日志攒成一个缓冲区再统一输出。批量大小的选择同样交给自适应逻辑。队列水位低的时候批量小一点保证日志能及时落盘水位高的时候批量大一点用吞吐换延迟。这里有个反直觉的点批量不是越大越好。批量太大单次输出的延迟就高而且一旦这批数据在输出过程中出问题丢失的量也大。所以 BqLog 给批量大小设了上限不会无限制地攒。// 批量聚合的伪代码逻辑 size_t batch_size adaptive_batch_size(current_watermark); LogEntry batch[MAX_BATCH]; size_t n ring_queue_dequeue_batch(q, batch, batch_size); if (n 0) { output_batch(batch, n); // 一次性输出 }实测下来批量聚合能把消费端的系统调用次数降低一到两个数量级整体吞吐提升非常明显。但要注意批量聚合会引入额外的内存拷贝所以批量缓冲区最好也是预分配的别在消费路径上再搞动态分配。4. 两个结构怎么咬合写入与消费的协同设计4.1 队列满时的降级策略丢谁、怎么丢再好的设计也架不住极端情况。如果生产端持续爆量消费端拼尽全力也追不上队列终究会满。这时候必须有明确的降级策略而且这个策略要提前想清楚不能等线上出问题了再临时拍脑袋。BqLog 的降级是分级的。第一级是丢弃低优先级日志比如 Debug 和 Verbose 级别的保留 Info 及以上的。第二级是采样丢弃对同类日志按比例丢弃比如每 10 条保留 1 条这样至少还能看出趋势。第三级才是整体丢弃并计数同时打一个日志丢失的标记方便事后分析。这里的关键是降级决策要在写入端快速做出不能有复杂计算。所以优先级判断要尽量简单采样可以用计数器取模别在热路径上搞随机数生成。我见过有的实现用rand()来决定是否采样结果rand()本身成了瓶颈这就本末倒置了。4.2 内存序与可见性跨线程传递数据的隐形陷阱环形队列和数据总线分属不同线程它们之间的数据传递依赖内存可见性保证。这块是最容易出微妙 bug 的地方因为问题往往在特定平台、特定负载下才暴露平时测试根本发现不了。核心原则是生产者写完数据后必须用 release 语义发布消费者读取前必须用 acquire 语义获取。这样能保证消费者看到计数更新时数据一定已经写好了。反过来消费者处理完释放槽位时也要用 release 语义让生产者知道这个位置可以复用了。// 生产者先写数据再发布计数 q-buffer[pos] entry; __atomic_store_n(q-length, new_length, __ATOMIC_RELEASE); // 消费者先获取计数再读数据 uint32_t len __atomic_load_n(q-length, __ATOMIC_ACQUIRE); LogEntry e q-buffer[read_pos];我在 ARM 设备上调试过一个诡异的问题日志偶尔会出现内容错乱x86 上完全复现不了。查了很久才发现是某处漏了 acquire 语义在 x86 的强内存模型下侥幸能跑到了 ARM 的弱内存模型就露馅了。这个坑提醒我跨平台的无锁代码内存序一定要严格按规范来不能靠平台特性蒙混过关。4.3 缓存行对齐别让伪共享偷走你的性能还有一个容易被忽视的细节是伪共享false sharing。环形队列的rear和length这两个变量如果放在同一个缓存行里生产者和消费者分别更新它们时会导致缓存行在两个核心之间来回弹跳性能急剧下降。解决办法是缓存行对齐把高频写的变量各自隔离到独立的缓存行typedef struct { alignas(64) volatile uint32_t rear; alignas(64) volatile uint32_t length; // ... } RingQueue;64 字节是主流平台的缓存行大小。这个改动看起来只是加了几个字节的填充但实测在高并发场景下吞吐能提升 20% 以上。代价是内存占用略微增加但对于日志组件这种对性能敏感的场景这笔账非常划算。5. 实测数据与调优心得5.1 不同负载下的表现对比我在一台 8 核 ARM 设备上做过一组对比测试模拟不同日志速率下的表现。测试场景是多个业务线程持续写入消费端单线程输出到文件。日志速率条/秒队列水位平均写入延迟丢日志比例10 万 20%约 60ns0%50 万约 45%约 75ns0%100 万约 70%约 110ns0%200 万 95%约 200ns约 3%可以看到在队列未满的情况下写入延迟增长是平缓的这说明无锁路径确实扛住了压力。真正开始丢日志是在 200 万条每秒这个量级而且丢的比例也不高说明自适应机制在尽力追赶。这个数据比我早期用加锁方案时好太多了——加锁版本在 50 万条每秒时就已经出现明显的线程阻塞。5.2 几个我踩过的调优坑第一个坑是队列大小拍脑袋定。一开始我按经验设了个 8192结果战斗场景下几分钟就满了。后来改成根据峰值速率动态估算留足缓冲才稳定下来。教训是队列大小要基于实测数据来定别凭感觉。第二个坑是消费线程优先级设太高。我一度把消费线程设成高优先级想着让它尽快处理结果它反而抢占了业务线程的 CPU导致帧率下降。后来把优先级调回正常靠自适应机制来调节整体表现反而更好。这说明消费端不是越快越好而是要和业务线程和谐共处。第三个坑是忽略了日志格式化本身的开销。写入环形队列很快但如果格式化字符串比如sprintf在写入路径上做那前面的优化全白费。BqLog 的做法是把格式化推迟到消费端写入端只存原始参数这样热路径上就没有昂贵的字符串处理了。5.3 什么场景下这套方案不适用说了这么多优点也得讲讲边界。环形队列加自适应数据总线这套方案最适合的是高吞吐、可容忍少量丢失、对写入延迟敏感的场景。如果你的场景是每条日志都不能丢那这套方案就不合适因为队列满时的降级必然会丢数据。这种情况下你得用阻塞式写入或者持久化队列但代价就是写入延迟不可控。另外如果日志量很小比如每秒几百条那这套复杂的机制反而是过度设计简单的同步写文件就够了。技术选型永远要看场景别为了炫技而上复杂方案。6. 把这套思路迁移到其他场景环形队列加自适应数据总线的组合其实不只能用在日志上。任何生产快、消费慢、且能容忍一定丢失的数据管道都可以借鉴这套思路。比如埋点上报、性能指标采集、甚至游戏内的战斗回放录制本质上都是同一个问题。迁移的时候核心要抓住三点写入端无锁化、内存预分配、消费端自适应。这三点做到了基本就能保证在高负载下不拖累业务。至于具体的队列大小、批量策略、降级规则那就要根据你的实际数据特征去调了。我自己后来把这套结构用在一个实时指标采集模块上效果同样不错。唯一需要调整的是降级策略——指标数据比日志更怕丢所以我把降级阈值设得更保守队列也开得更大。这再次说明框架是死的参数是活的理解原理比记住结论重要得多。最后分享一个小心得调试这类无锁结构时普通的断点调试基本没用因为会破坏时序。我一般靠日志埋点和压力测试来定位问题必要时用 ThreadSanitizer 这类工具来检测数据竞争。这套组合拳下来大部分并发 bug 都能揪出来。