为何同一Dask Worker上的任务无法复用缓存工厂方法的缓存对象？

核心疑问解答 #

1. PID是否在任务间变化？
   同一Worker进程内的所有任务共享相同PID，Worker进程启动后PID固定，不会随任务执行改变，因此这不是问题根源。

2. Python解释器是否在任务间重置？
   Dask Worker进程会持续运行，解释器状态在任务间保持稳定，类级别的缓存变量不会被自动重置，因此这也不是原因。

可能的问题根源 #

1. 缓存键计算错误 #

你的数据库管理器类的__hash__方法需确保同时包含当前进程PID和完整的连接参数（dbhost、dbuser、dbpass、dbname）。如果哈希值未正确覆盖这些信息，会导致同一进程内相同配置的实例生成不同哈希，缓存无法命中。比如：

• 若__hash__未包含PID，不同进程的相同配置实例会有相同哈希，但同一进程内仍应正常复用；
• 若漏加某个连接参数（如dbpass），不同密码的实例会被误判为相同，但你场景中参数一致，更可能是PID未正确纳入哈希。

2. 线程安全竞态条件 #

Dask Worker默认使用线程池模式，多个任务会并发调用get方法。当第一个任务还未将实例写入缓存时，后续任务可能同时进入KeyError分支，重复创建新的管理器实例，最终每个任务都生成独立数据库连接。

3. 模块重复加载导致缓存重置 #

如果你的数据库管理器类定义在__main__模块中，Dask Worker执行任务时可能会重新加载该模块，导致类级别的_db_manager_cache被重置为空。将类移到独立模块并通过导入引用可解决此问题。

4. 缓存变量类型错误 #

确认_db_manager_cache是类的静态变量而非实例变量。如果是实例变量，每次调用get时都会使用新的缓存字典，自然无法复用之前的实例。

验证与修复建议 #

• 添加调试日志：在get方法中打印当前PID、缓存键以及缓存中的所有键，确认同一进程内相同配置的实例是否生成相同哈希，以及缓存中是否存在该键：

  import os
  def get(dbhost, dbuser, dbpass, dbname):
      new_db_manager = cls(dbhost, dbuser, dbpass, dbname)
      cache_key = hash(new_db_manager)
      logger.info(f"Current PID: {os.getpid()}, Cache key: {cache_key}, Existing keys: {list(cls._db_manager_cache.keys())}")
      try:
          return cls._db_manager_cache[cache_key]
      except KeyError:
          cls._db_manager_cache[cache_key] = new_db_manager
          logger.info(f"New DB manager initialized {cls}, PID: {os.getpid()}")
          return new_db_manager
  

• 添加线程锁：解决并发场景下的竞态条件，确保缓存读写操作原子性：

  import threading
  # 在类定义中初始化锁
  cls._cache_lock = threading.Lock()
  
  def get(dbhost, dbuser, dbpass, dbname):
      new_db_manager = cls(dbhost, dbuser, dbpass, dbname)
      cache_key = hash(new_db_manager)
      with cls._cache_lock:
          try:
              return cls._db_manager_cache[cache_key]
          except KeyError:
              cls._db_manager_cache[cache_key] = new_db_manager
              logger.info(f"New DB manager initialized {cls}, PID: {os.getpid()}")
              return new_db_manager
  

• 确认Worker执行模式：通过dask worker命令参数确认使用的是进程池还是线程池。进程池模式下每个Worker进程有独立缓存副本，连接数应等于Worker进程数；线程池模式下需保证缓存线程安全。

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