服务扩展、存储与并发

选择独立或共享 runtime，区分粘性路由、共享存储和会话级并发控制。

This page has not been translated into English yet. The original Chinese version is shown below.

扩展部署要同时考虑 runtime 数量、会话归属、状态位置和同一会话的并发访问。增加服务副本本身不会解决这些问题。

三种部署模式

模式	取舍
每用户独立 CLI	分离进程、身份与会话，资源成本更高；还需为状态目录和工具范围建立实际边界
共享 CLI、不同 session	资源较低，应用必须使用 empty 模式、会话身份和归属校验
多用户共享同一 session	适合协作，但要共同授权并串行化写入

旧 scaling 示例只使用 session 命名规则，部分表格把共享方式限制为 service token；较具体的 multi-tenancy 章节已明确支持会话级用户 token，并要求 mode: "empty"。本页按专门配置规则补全，不把旧简化例子当作完整服务器实现。

SDK 不提供内置 session locking。多个用户或请求写同一会话时，应用必须串行化操作，可使用 Redis 等外部协调机制。

官方锁示例用于解释流程；产品实现还需保证锁归属判断与释放不会产生竞态，任务可能超出租约时需处理租约有效性。共享存储也不自动提供 session 写锁。

Sticky sessions 把同一用户路由到同一 CLI，部署简单，不必共享每台机器的会话文件，但负载可能不均。

共享存储 使其他 CLI 能恢复同一 session，便于重新路由；官方文件方案共享 ~/.copilot/session-state/ 或自定义根目录对应位置。使用应用存储时，可评估sessionFs。

不论哪种方式，都需要应用维护 session owner、选择 runtime，并在恢复前验证权限。SDK 没有内置负载均衡器。

限制并发数量、释放不活跃会话、定期清理到期状态，可以减轻内存与磁盘压力。示例中的 50 并发是应用调优样例，不是 SDK 固定上限。

disconnect 可释放活动连接并保留可恢复状态；deleteSession 删除会话。命名会话与持久卷解决的是恢复需求，不应把 infiniteSessions 的上下文压缩设置当作存储或访问控制方案。

默认没有 idle timeout。由 SDK 启动 runtime 时设置 sessionIdleTimeoutSeconds；独立 headless 服务用 --session-idle-timeout <seconds>。具体保留时长由产品需求决定。

监测活跃会话数、响应延迟与错误率，保持 runtime 健康检查；停止前排空在途会话。容器需持久状态时挂载对应目录，秘密信息使用部署平台的凭据管理。进程级隔离、用户身份和文件存储三者都要符合所选部署模式。