基于Firestore排行榜的50人上限用户分组实现方案咨询

嘿，刚好做过类似的游戏团队分配需求，结合Firestore的特性，给你梳理一套能抗并发、易扩展的方案👇

核心原则 #

首先得明确：团队分配必须保证原子性，不然高并发注册时，很容易出现多个用户同时挤进一个已经满50人的团队，这是绝对要避免的。Firestore的事务就是解决这类问题的核心工具。

数据结构设计 #

先把集合结构定清楚，尽量简洁且满足需求：

• users 集合：每个用户文档包含核心字段：
  • teamId：关联的团队ID（必填）
  • joinTimestamp：用户注册时间（用于先到先得的排序依据）
  • score：游戏分数（用于排行榜）
• teams 集合：每个团队文档包含：
  • memberCount：当前成员数（实时更新，初始为1）
  • maxMembers：固定为50（可配置）
  • createdAt：团队创建时间（用于优先分配到最早的未满员团队）

核心分配逻辑（用事务实现） #

所有分配操作必须在后端执行（比如Firebase云函数），禁止前端直接操作，避免安全风险。下面是Node.js的示例代码：

const admin = require('firebase-admin');
admin.initializeApp();
const db = admin.firestore();

// 给新用户分配团队的核心函数
async function assignTeamToUser(userId) {
  let assignedTeamId = null;

  // 用事务保证原子操作：查团队→更新/创建团队→记录团队ID
  await db.runTransaction(async (transaction) => {
    // 1. 优先找最早创建的未满员团队（先到先得的核心）
    const availableTeamsQuery = db.collection('teams')
      .where('memberCount', '<', 50)
      .orderBy('createdAt', 'asc')
      .limit(1);
    
    const teamsSnapshot = await transaction.get(availableTeamsQuery);

    if (!teamsSnapshot.empty) {
      // 2. 找到未满员团队，更新成员数
      const teamDoc = teamsSnapshot.docs[0];
      const updatedCount = teamDoc.data().memberCount + 1;
      transaction.update(teamDoc.ref, { memberCount: updatedCount });
      assignedTeamId = teamDoc.id;
    } else {
      // 3. 没有可用团队，创建新团队
      const newTeamRef = db.collection('teams').doc();
      transaction.set(newTeamRef, {
        memberCount: 1,
        maxMembers: 50,
        createdAt: admin.firestore.FieldValue.serverTimestamp()
      });
      assignedTeamId = newTeamRef.id;
    }
  });

  // 4. 把团队ID绑定到用户文档（也可以放到事务里，更严谨）
  await db.collection('users').doc(userId).update({ 
    teamId: assignedTeamId,
    joinTimestamp: admin.firestore.FieldValue.serverTimestamp()
  });

  return assignedTeamId;
}

// 可以绑定到用户创建的触发器
exports.onUserCreate = functions.auth.user().onCreate(async (user) => {
  await assignTeamToUser(user.uid);
});

优化与扩展建议 #

1. 索引优化 #

给teams集合创建复合索引：memberCount（升序） + createdAt（升序），这样查询未满员团队的速度会快很多，避免全表扫描。

2. 缓解热点问题 #

如果你的游戏用户量极大，所有请求都去抢最早的团队，会导致这个团队文档成为热点（Firestore对单个文档的写入QPS有限制）。可以做以下优化：

• 按时间分片创建团队池：比如每小时自动创建一批空团队，用户分配时随机从当前池的未满员团队里选，分散写入压力
• 给团队ID加前缀哈希：比如按用户ID的哈希值分配到不同的团队分组，避免所有请求集中在少数团队

3. 排行榜实现 #

团队内的排行榜直接用users集合的复合索引就能搞定：
创建索引：teamId（升序） + score（降序），然后查询某个团队的排行榜只需：

async function getTeamRanking(teamId, limit = 10) {
  const rankingSnapshot = await db.collection('users')
    .where('teamId', '=', teamId)
    .orderBy('score', 'desc')
    .limit(limit)
    .get();
  
  return rankingSnapshot.docs.map(doc => ({
    userId: doc.id,
    score: doc.data().score,
    // 其他需要展示的字段
  }));
}

4. 是否需要用其他工具？ #

• 分布式计数器：没必要，50人上限的场景下，普通事务完全能处理并发，分布式计数器适合百万级别的计数场景
• 云函数触发器：强烈推荐，把分配逻辑绑定到用户创建的触发器，用户注册后自动分配团队，无需前端干预
• 安全规则：一定要给users和teams集合设置安全规则，禁止用户篡改teamId和memberCount字段，比如：

  rules_version = '2';
  service cloud.firestore {
    match /databases/{database}/documents {
      match /users/{userId} {
        allow read: if request.auth.uid == userId;
        allow update: if request.auth.uid == userId && !request.resource.data.hasAny(['teamId']);
      }
      match /teams/{teamId} {
        allow read: if true;
        allow write: if false; // 只允许云函数修改
      }
    }
  }
  

常见坑点 #

• 不要在前端直接查询团队再分配：前端的查询和更新不是原子操作，高并发下必出问题
• 不要把所有团队的人数统计存到一个单独的计数器文档：会导致严重的热点问题，每个团队自己存memberCount才是正确的方式
• 一定要用serverTimestamp()：避免客户端时间不一致导致的排序错误

内容的提问来源于stack exchange，提问作者Scooby Don't