Python logging.handlers.RotatingFileHandler 为什么会重复切日志：maxBytes、backupCount 与并发写入边界

线上服务突然出现了 app.log、app.log.1 和 app.log.2 轮番变大的情况，第一反应往往是把 maxBytes 再调小一点。这个判断只对了一半：RotatingFileHandler 的大小判断发生在写入前，而多进程共享一个日志文件时，真正的问题常常是多个进程同时决定“现在该轮转”。

先看清楚轮转是被什么信号触发

它不是后台定时任务，也不会持续监视文件大小。每次调用 emit() 时，处理器先检查当前文件是否需要轮转，再写入这一条日志。因此一条很长的异常堆栈可能让文件越过阈值，实际大小不会精确停在 maxBytes。

最小配置可以这样写：

import logging
from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler(
    "app.log",
    maxBytes=10 * 1024 * 1024,
    backupCount=3,
    encoding="utf-8",
)
handler.setFormatter(logging.Formatter(
    "%(asctime)s %(process)d %(levelname)s %(message)s"
))

logger = logging.getLogger("worker")
logger.setLevel(logging.INFO)
logger.addHandler(handler)

这里的 process 字段很重要。后面排查多进程竞争时，先知道是哪一个进程写入，比盯着文件名猜测可靠得多。

用一个可控实验确认 backupCount 的实际结果

把阈值临时设为 200 字节，连续写入足够多的短消息，观察文件链，而不是只看当前 app.log：

for index in range(80):
    logger.info("request=%03d status=200 payload=rotation-check", index)

正常的单进程结果通常是 app.log、app.log.1、app.log.2、app.log.3。当下一次轮转发生时，原来的 .3 会被淘汰，.2 移到 .3，依次类推；不会因为把 backupCount 设为 3 就得到三个“额外永久文件”。

重复切分通常发生在多进程共享文件时

假设 Gunicorn、multiprocessing 或多个独立 worker 都各自创建了一个指向 app.log 的 RotatingFileHandler。进程 A 和进程 B 都看到文件已经接近阈值，于是分别执行重命名。文件系统的重命名动作本身可能成功，但两个处理器内部的文件对象、编号判断和下一次写入并没有形成跨进程协议。

于是你可能看到这些症状：

• 轮转频率明显高于单进程实验，文件大小忽大忽小。
• 某些进程的日志突然进入旧编号，或者同一时间段的记录分散到多个文件。
• backupCount 看起来没有生效，因为另一个进程刚建立的编号又被覆盖或移动。

这不是把阈值调大就能根治的问题。线程共享同一个处理器时，处理器自己的锁可以帮助同一进程内的线程；它不能替多个进程协调轮转顺序。

上线处理按优先级选择一种收敛方式

方案一：每个进程写独立文件

在文件名中加入 worker 标识，例如 app-worker-03.log。每个处理器只负责自己的文件，轮转结果最容易验收，代价是日志采集端需要用通配符收集多个文件。

方案二：进程只把记录交给集中写入者

应用进程使用 QueueHandler，由一个独立监听者持有唯一的 RotatingFileHandler。这样大小判断和编号移动都在一个进程内完成。监听者停机时要先停止接收，再排空队列，最后关闭文件；否则轮转问题解决了，停机丢日志又会出现。

方案三：让外部日志系统负责轮转

容器或平台环境通常更适合标准输出加采集器，由采集侧处理保留周期和压缩。若必须由 Python 管理文件，先明确谁拥有轮转权，不要让 Python 处理器和外部 copytruncate 同时改同一个文件。

回滚与验收不要只检查文件数量

如果新配置导致日志切得过于频繁，回滚时恢复上一个已验证的阈值和文件名格式，同时保留一份现场目录清单。不要直接删除旧备份，否则无法判断是处理器淘汰了文件，还是采集任务清理了文件。

python - 

验收至少包括三件事：单进程连续写入时编号按预期递进；多进程模式下不存在共享文件的多个轮转拥有者；进程号和时间戳能够让采集端重建一条完整事件链。

常见问题

maxBytes 设置了，为什么文件还是超过阈值？

因为检查发生在当前记录写入前，单条日志或异常堆栈可以一次跨过阈值。它不是硬截断器。

backupCount=0 会不会保留当前文件？

当前文件仍会写入，但不会保留编号备份。需要历史窗口时，应明确设置正整数并结合磁盘容量验收。

加一把 multiprocessing 锁就能共享轮转吗？

只有所有进程确实共享同一把、生命周期可靠的进程间锁，并且覆盖完整轮转协议时才可能协调；实际部署更建议独立文件或集中写入，减少隐含状态。

一张清单收尾

先用单进程小阈值实验确认 maxBytes 与 backupCount，再核对生产启动模型。如果一个文件由多个进程直接持有，就在发布前改成独立文件或单一写入者。最后把轮转前后的目录、进程号、采集结果和停机排空结果一起纳入验收，重复切分才有机会真正收敛。