活动、排行、匹配与社交

Category

system / 通用服务子树。节点定位：活动、排行、匹配、社交四件平台化候选——各自真正的难点（规则执行、口径与更新成本、不是凑满人、关系与治理）与判断方式。

Definition

这几类系统经常被放在同一章，不是因为它们实现方式相同，而是因为它们都带有很强的“运营放大器”特征。平时流量平稳时，它们看起来只是一些外围能力；一旦新赛季上线、活动开启、主播带量或者节假日返场，这些系统就会同时变成流量中心、争议中心和故障中心。

Problem

这四件最容易被做成「页面 + 数据库表」：活动难在规则执行不是页面，排行难在口径与更新成本，匹配不是排队凑满人，社交难在关系与治理。难点错了，做出来的系统中看不中用。

为什么它们会成为平台化候选

活动、排行、匹配和社交都具备几个共同特征：

• 规则经常变化，版本和运营节奏强相关
• 读多写多且峰值明显，容易在固定时间点爆量
• 需要连接多个业务系统，例如战斗结果、资产发奖、好友关系、聊天、公会、邮件
• 很难只靠数据库表描述，往往还需要调度、状态机、实时计算和后台工具

因此团队常常会问：这些能力应该做成项目内模块，还是做成平台服务？答案通常不统一，因为四者的“共性程度”其实不同。

活动系统的难点不在页面，而在规则执行

活动系统最容易被低估。表面上它像一个后台配置问题，实际上它牵涉：

• 开启关闭时间和时区处理
• 人群过滤与灰度开关
• 条件累计、任务进度、领奖状态
• 资源投放和资产补发
• 与版本更新、渠道审核、支付活动的联动

很多团队早期用“配置表 + if else”快速实现，短期很有效，但活动类型一多就会出现两个问题：

• 配置表达力不足，只能不断加特殊字段和特殊逻辑
• 配置表达力过强，运营能拼出没人真正理解的执行路径

所以活动系统通常要在“模板化”和“脚本化”之间找平衡。模板化更安全、可复用、易审计；脚本化更灵活，但测试和回滚成本高。长线项目一般会把高频活动做成标准模板，把少数复杂活动放在受控扩展点中，不让所有活动都走自定义脚本。

排行榜的核心问题是口径和更新成本

排行榜不是一个 Redis zset 就结束了。真正难的是三件事：

• 排名依据是什么，口径是否稳定
• 更新是实时写入、准实时汇总还是离线结算
• 奖励发放和申诉处理如何对账

不同排行榜的实现差异很大：

• 战力榜强调查询快和展示稳定，但战力本身可能是聚合值，更新链路很长
• 竞速榜强调写入实时性和作弊校验，否则前几名会持续被争议
• 公会榜和跨服榜会牵涉分区、分组、赛季切换和奖励批处理

如果没有稳定口径，排行榜会变成运营事故源。典型问题包括：

• 战力计算版本切换后，老数据没重算，榜单一夜之间错位
• 跨服榜分组逻辑调整，部分玩家被分到错误池子
• 榜单结算后又收到延迟战绩，补算时没有补偿规则

匹配系统不是“排队后凑满人”

匹配系统真正要平衡的是等待时间、公平性、可感知质量和系统成本。房间制轻度游戏往往能接受简单的 Elo 或分段区间放宽策略，但强实时竞技游戏会受到更多限制：

• 网络质量是否纳入匹配条件
• 组队与单排是否共池
• AI 或机器人是否参与兜底
• 跨区匹配会不会放大延迟和作弊风险

匹配系统如果做得过于独立，会脱离游戏真实体验；如果完全内嵌在战斗服里，又很难跨模式复用和做大盘调度。常见做法是：

• 用统一匹配服务维护池子、分桶、策略和队列状态
• 用业务侧提供真实能力标签，例如段位、英雄池、网络质量、组队结构
• 用房间或战斗服务负责最终建房和开局校验

这里最容易犯的错，是把匹配结果当成最终事实，而忽略“入房前最后一跳”的校验。实际上，断线、切后台、队伍变更、服务负载变化都可能让一个看似合格的匹配结果在落房时失效。

社交系统的真正难点是关系和治理

好友、公会、聊天、私信、黑名单、师徒、组队邀请看起来属于“社区功能”，但它们会显著改变数据模型和治理成本。

只要项目社交做重，就必须回答下面这些问题：

• 好友关系是单向还是双向，删除和拉黑如何传播
• 公会成员、职位、审批、日志和贡献由谁维护权威状态
• 聊天消息需要保存多久，哪些频道需要审核或回溯
• 未成年人保护、举报处理和禁言处罚怎样落到具体系统

社交系统很难完全项目内闭环，因为它天然和风控、客服、审计系统相连。一个成熟做法通常是：

• 关系状态由社交服务维护
• 业务事件通过标准接口投喂社交展示层
• 聊天和举报走独立治理链路
• 公会战、组队副本等强玩法逻辑仍保留在项目业务服务

设计时更有用的判断方式

与其问“活动、排行、匹配、社交能不能共用”，不如分别问：

• 哪些规则变化频率最高，因此需要后台可配
• 哪些状态最敏感，因此必须有强审计和强幂等
• 哪些链路是峰值流量入口，因此必须单独扩容和限流
• 哪些能力跨多个玩法模式复用，因此值得抽成平台服务

常见错误

• 为了复用，把所有活动都塞进一个超复杂活动引擎，结果谁也不敢改
• 只做排行榜展示，不做口径管理、赛季归档和奖励对账
• 匹配策略只看数值公平，不看网络质量、队伍结构和等待体验
• 把社交当成 UI 功能，不做举报、禁言、日志留存和权限治理

这些系统的共同规律是：一旦它们对收入、留存和舆情有实质影响，就不能再按“外围功能”对待。它们需要的不是更多页面，而是更清晰的状态边界、更完整的后台工具和更强的线上治理能力。

Used By

四系统设计评审；平台化建设排序；与专用节点的分工核对。

• Nakama（commit e920249）：四件套齐活的参照——匹配池按 query 与数值范围查询筛候选（server/matchmaker_process.go:75-78）、组队预分组（server/matchmaker.go:139），榜单三件套缓存/名次/调度（server/leaderboard_cache.go、leaderboard_rank_cache.go:34、leaderboard_scheduler.go:84-91）

Related

关系链：平台化候选 → 活动 → 排行 → 匹配 → 社交 → 判断方式 → 常见错误。上游：services/01（基础件底座）。下游：system 三节点（排行榜、队伍匹配、PVP 匹配的机制展开）、server/sync（对局支撑）。

Reference

本页为工程经验归纳。