多Docker容器部署Python服务时uuid4重复问题排查

数据老陈

2026-8-26

问题根因说明

首先纠正一个认知错误：uuid.uuid4()底层调用的os.urandom(16)走操作系统密码学安全随机数生成器（CSPRNG），完全不依赖CPU名称这类静态硬件信息——只有v1版本UUID才会把MAC地址作为生成因子。你遇到的每小时1次的重复问题，理论碰撞概率和你计算的4e-31偏差极大，只可能来自两类原因：

代码逻辑缺陷导致同一个UUID被赋值给多条数据
容器环境随机源异常导致随机数序列重复

排查优先级

先排查异步代码的可变对象复用问题
你的函数是async异步实现，如果上层调用时在循环/并发场景下重复传入同一个dict实例作为kwargs，异步调度时会出现多个协程先后修改同一个dict的uuid字段，最终序列化时拿到重复值。这是Python异步代码里出现重复ID的最高频原因，排查成本极低：在给uuid赋值后打印id(kwargs)和对应的UUID值，出现重复时如果两个条目对应的kwargs内存id一致，就能确认是这个问题。
再排查Docker环境随机源问题
2018年之前的旧版本Docker存在批量启动容器时未正确初始化CSPRNG状态的bug，在宿主机熵值不足、容器启动后立刻生成大量随机数的场景下，不同容器会输出重复的随机数序列。此外使用过度裁剪的精简镜像、错误配置随机数挂载、用伪随机文件替换/dev/urandom也会触发同类问题。
排查方式：批量启动20个服务容器，每个容器启动后立刻连续生成1000个UUID落盘，跨容器对比是否存在重复序列；也可以进容器连续执行cat /proc/sys/kernel/random/uuid20次以上，看是否出现重复值。

解决方案

按改造成本从低到高排序：

修复可变对象复用问题
不要直接修改上层传入的kwargs可变对象，每次调用时生成本地副本再操作，修改后的核心代码如下：

import copy
import uuid
import pickle

async def create_object_from_kwargs(object_: Type[T], **kwargs) -> T:
    # 生成本地独立副本，避免并发场景下的变量覆盖
    local_kwargs = copy.deepcopy(kwargs)
    for k, v in local_kwargs.items():
        if isinstance(v, uuid.UUID):
            local_kwargs[k] = str(v)

    local_kwargs['uuid'] = str(uuid.uuid4())
    data = {
        'model': object_.__tablename__,
        'data': local_kwargs
    }
    serialized_data = pickle.dumps(data)
    # 发送到Kafka
    await producer.send_and_wait(KAFKA_NAME, serialized_data)

    item = object_(**local_kwargs)
    return item

修复容器随机源问题
- 升级Docker版本到20.10以上，修复旧版本CSPRNG初始化bug
- 在宿主机安装rng-tools补充系统熵池，避免随机源因为熵不足输出重复序列
- 不要手动给随机数生成器设置固定种子，手动设种会大幅提升碰撞概率
可选ID生成方案优化
如果想要进一步降低碰撞概率，可以换用UUIDv7（Python 3.11+原生支持，低版本可引入兼容实现）：UUIDv7以毫秒级时间戳为前缀，后缀为随机数，即使随机源短暂异常，不同时间生成的ID也不会重复，同时还能保持ID的时序性，更适合数据库存储场景。
兜底防护
在批量拉取Kafka数据入库的逻辑里加一层批次内去重：检测到批次内存在重复UUID时，给重复条目重新生成ID再入库，几行代码就能彻底挡住重复键报错，不依赖上游逻辑的正确性。

注：你观察到的「报错提示UUID已存在但表里查不到对应行」，大概率是数据库事务可见性导致的：同批次内两条重复UUID的数据在同一个事务里插入，第一条插入时还没提交，第二条插入触发唯一键冲突时，事务还没提交所以你查不到对应行，这也能佐证重复UUID是出现在单批次数据内部，和存量1.5亿行数据无关。

内容的提问来源于stack exchange，提问作者Ivan

多Docker容器部署Python服务时uuid4重复问题排查

排查优先级 #

排查优先级