Firebase Admin Node 中并发请求的令牌优化策略

在 Firebase Admin Node 项目中，开发者发现了一个关于消息发送接口的性能优化点。当使用 Messaging#sendEach 方法批量发送消息时，系统会为每条消息单独获取访问令牌，这在并发场景下会导致不必要的令牌获取请求。

问题背景

Firebase Admin SDK 中的消息发送功能需要有效的访问令牌来授权 API 调用。在批量发送场景下，每条消息都会触发一个独立的 HTTP 请求。虽然 SDK 内部实现了令牌缓存机制，但由于这些请求是并发执行的，缓存机制无法有效发挥作用。

具体表现为：当多个请求几乎同时到达时，每个请求都会检查缓存并发现令牌需要刷新，于是各自发起独立的令牌获取请求。这不仅增加了网络开销，还可能导致短时间内产生大量冗余请求。

解决方案分析

针对这个问题，项目维护者提出了两种可能的解决方案：

1. 预获取令牌方案：在发送批量请求前预先获取令牌，然后将该令牌注入到每个发送请求中。这种方法直接避免了并发获取令牌的问题，但需要对现有请求处理流程进行一定改造。

2. 令牌请求合并方案：改进 getToken() 方法的实现，使其能够识别并合并并发的令牌刷新请求。当多个调用同时请求令牌时，系统只执行一次实际的刷新操作，并将同一个 Promise 返回给所有调用者。

经过讨论，第二种方案被认为更具通用性，因为它不仅解决了消息发送场景的问题，还能惠及所有需要授权访问的并发请求场景。

技术实现细节

令牌请求合并的核心实现思路是：

public getToken(forceRefresh = false): Promise<FirebaseAccessToken> {
  if (forceRefresh || this.shouldRefresh()) {
    if (!this.isRefreshing) {
      this.promiseToCachedToken_ = this.refreshToken();
    }
    return this.promiseToCachedToken_
  }
  return Promise.resolve(this.cachedToken_);
}

这段代码引入了几个关键机制：

• isRefreshing 标志位：作为锁机制，防止重复刷新
• 共享 Promise：所有并发请求共享同一个刷新操作的结果
• 缓存机制：在令牌有效期内直接返回缓存结果

方案优势

这种改进方案具有以下优点：

1. 减少网络请求：有效避免了令牌刷新请求的"惊群效应"
2. 保持API兼容性：不需要改变现有方法签名和使用方式
3. 通用性强：适用于所有需要授权访问的场景
4. 实现简洁：改动量小，风险可控

总结

在分布式系统和并发编程中，资源共享和请求合并是常见的优化手段。Firebase Admin Node 通过对令牌获取逻辑的改进，展示了如何优雅地处理并发场景下的资源竞争问题。这种模式也可以为其他需要处理类似问题的开发者提供参考。

对于使用 Firebase Admin SDK 的开发者来说，这一改进将带来更高效的批量消息发送体验，特别是在高并发场景下能够显著减少不必要的网络开销。