性能与扩展

Skrum 是一体化的 AI 项目控制平台——团队聊天、任务与冲刺、原生视频会议、以及入站代码活动,全部集中在一个工作空间中,每一项 AI 操作都会等待人工确认后才会执行。

Skrum 经过精心设计,即便在工作空间不断增长以及基础设施出状况的日子里,依然保持响应。本页记录了具体数字、缓存模型以及故障模式。

负载阈值

位于 load/ 下的可选 k6 场景在使用确定性伪造提供方的组合栈上,将 Skrum 约束在下列目标之内:

• 实时扇出 — 单个频道内 500 个并发套接字客户端,消息到扇出的 p95 延迟 ≤ 250 ms,错误率 < 0.1%。
• POST 消息 — 50 rps 下 p95 ≤ 200 ms,错误率 < 0.5%。
• 看板读取 (GET /api/tasks?projectId=…) — 100 rps 下 p95 ≤ 150 ms,错误率 < 0.5%。
• 搜索 (GET /api/search) — 50 rps 下 p95 ≤ 300 ms,错误率 < 1%。
• 主页摘要 (GET /api/home/summary) — 100 rps 下 p95 ≤ 200 ms,错误率 < 0.5%。

读穿缓存

一个由 Redis 支撑的小型读穿缓存覆盖了三条热点路径:每个工作空间的频道列表、项目看板投影,以及仪表盘/主页摘要。每个键都以工作空间的 accountId 作为前缀 —— 工作空间只能读取自己缓存下来的数据。失效由实时主干上的事件驱动(message.posted、channel.*、task.*),并以较短的 TTL 作为兜底。缓存仅存储已授权、非敏感的投影。

混沌韧性

当依赖出现故障时,Skrum 选择安全失败,而不是写入一半或让数据外泄。

• Redis 宕机。 实时与缓存降级;REST 仍然从 Mongo 与 Postgres 提供真相之源。速率限制器安全失败(一律拒绝,决不放行)。
• Mongo 或 Postgres 不可达。 路由返回本地化的 503 类错误 —— 没有未处理的崩溃,也没有部分写入。
• MinIO 或 LiveKit 宕机。 文件上传与会议以本地化错误安全失败;应用其余部分继续工作。参见 备份与恢复。

依赖恢复之后,服务会自动恢复 —— 无需手动重启。

常见问题

• 是否在 CI 中运行 k6 套件? 是的,作为可选任务运行。负载场景永远不会阻塞常规的 pull request。
• 可以调高缓存 TTL 吗? TTL 有意保持较短。事件驱动的失效才是主要的正确性路径,TTL 只是 Redis 故障时的兜底。
• 缓存会不会在工作空间之间泄露? 不会 —— 每个键都以 accountId 前缀,一项专门的测试证明了租户之间的隔离。

另请参阅: Skrum 文档