MongoDB Atlas 和 AWS Lambda 之间的间歇性超时问题

Question

在这个问题上我有点绝望:我们正在为我们的API运行AWS Lambda，该API与MongoDB Atlas (M20)上的MongoDB集群对话。为了防止在每次lambda调用时创建新的连接，我们遵循以下模式:https://docs . atlas . MongoDB . com/best-practices-connecting-to-AWS-Lambda/在Lambda容器的生命周期内缓存连接。我们有一个小小的变化:

async function getProdDB() {
  const url = `mongodb+srv://${process.env.DB_USER}:${process.env.DB_PASSWORD}@xxxxx-yyyy.zzzzz.net?retryWrites=true`

  if (!cachedDb || !cachedDb.serverConfig.isConnected()) {
    cachedClient = await MongoClient.connect(
      url,
      { useNewUrlParser: true, useUnifiedTopology: true }
    )
    cachedDb = cachedClient.db(process.env.DB_NAME)
  }

  return cachedDb
}

这也检查我们是否连接。现在，这在98%的情况下都有效，但是我们的Lambda调用时不时会超时。我们试着诊断了一下:

< li >我们将Lambda的超时限制从6s更改为30s/60s，Lambda函数仍会不时超时。Mongo从不抛出错误，总是Lambda由于TimeoutError而完成调用 < li >如果调用成功或不成功，< code > cache DDB . server config . is connected()返回true ` < li >导致超时的业务逻辑部分是对MongoDB本身的查询，常见的MongoDB操作如对非常小的集合(最多100个文档)的< code>findOne或< code > update one < li >我们尝试在https://github.com/Automattic/mongoose/issues/8180之后将NodeJS上的MongoDB驱动程序从< code>3.3.1升级到< code>3.3.5(不过我们没有使用mongoose，只是使用了官方的mongodb NodeJS驱动程序),但问题仍然存在 < li >我们尝试通过使用相同版本驱动程序的NodeJS脚本直接查询我们的MongoDB集群，在数千次查询中，没有出现一次超时问题。所以我们得出结论，问题不在于我们的集群本身，而在于连接。 < li >调用非常频繁的函数不会比定期调用的函数更频繁地超时，但是调用不太频繁。看起来，我们到MongoDB的缓存连接不知何故变得陈旧了，即使在调用< code>isConnected()时返回< code>true，并且在Lambda容器保持打开一段时间而没有调用之后不能被重用。我们使用默认超时:https://scale grid . io/blog/understanding-MongoDB-client-time out-options/ < li >检查了Atlas上的MongoDB日志条目-没有任何可疑之处 < li >停止检查数据库连接解决了这个问题，但会使大多数API调用变慢2-3倍，我们仍然希望了解问题的根源

有没有人面临类似的问题，或者可以建议我们如何有效地解决这个问题？

Answer 1

我们公司目前使用相同的架构（Lambda-

以下是我们使用的代码：

public static async connect(url?: string): Promise<Db> {
    /** If MongoDB is already connected, return that */
    if (this.cachedDb && this.client && this.client.isConnected())
      return Promise.resolve(this.cachedDb);

    /** Check for MongoURL in env if not provided */
    const mongoUrl: string = url || process.env.MONGO_CONNECTION_URL || '';

    this.client = await MongoClient.connect(mongoUrl, {
      useUnifiedTopology: true,
      useNewUrlParser: true,
      ignoreUndefined: true,
    });

    this.cachedDb = this.client.db();

    return Promise.resolve(this.cachedDb);
  }

然后，我们稍后在同一MongoClient上使用缓存的数据库和客户端：

/**
 * MongoDB Client Class
 */
class MongoDbClient {
  private static cachedDb: Db | null = null;
  private static client: MongoClient | null = null;

  /**
   * Connects to a MongoDB database instance
   *
   * @param url The MongoDB connection string
   *
   * @returns An instance of a MongoDB database
   */
  public static async connect(url?: string): Promise<Db> {
    /** If MongoDB is already connected, return that */
    if (this.cachedDb && this.client && this.client.isConnected())
      return Promise.resolve(this.cachedDb);

    /** Check for MongoURL in env if not provided */
    const mongoUrl: string = url || process.env.MONGO_CONNECTION_URL || '';

    this.client = await MongoClient.connect(mongoUrl, {
      useUnifiedTopology: true,
      useNewUrlParser: true,
      ignoreUndefined: true,
    });

    this.cachedDb = this.client.db();

    return Promise.resolve(this.cachedDb);
  }

  /**
   * Retrieves the first document that matches a filter condition
   *
   * @param collectionName The name of the collection to search
   * @param filter The filter to search for
   * @param options MongoDB find one option to include
   *
   * @returns The first document that matches the filter condition
   */
  public static async findOne<T>(
    collectionName: string,
    filter: FilterQuery<T> = {},
    options: FindOneOptions<T extends T ? T : T> = defaultDocumentOptions
  ): Promise<T | null> {
    const db = await this.connect();
    return db.collection<T>(collectionName).findOne<T>(filter, options);
  }
}

我注意到的不同之处在于，我们正在检查MongoClient是否与Db连接。此后，版本 4 中的驱动程序使用以下代码在内部弃用和处理了此问题：

// If a connection already been established, we can terminate early
  if (mongoClient.topology && mongoClient.topology.isConnected()) {
    return callback(undefined, mongoClient);
  }

可能发生的另一件事是Lambda偶尔会被破坏/损坏。对于Lambda来说，这是无法预防的正常行为，这就是为什么AWS建议在您的程序中内置重试策略。

请注意，即使是AWS SDK，其文档中也有重试策略：

AWS CLI和AWS SDK等客户端会重试客户端超时、节流错误(429)和其他不是由错误请求导致的错误。