ModelContextProtocol TypeScript SDK 中的无状态传输实现方案

前言

在现代分布式系统中，服务端的高可用性通常通过多节点部署来实现。然而，当涉及到需要保持会话状态的通信协议时，这种架构就会面临挑战。ModelContextProtocol TypeScript SDK 中的 StreamableHTTP 和 SSE 传输实现最初采用了内存缓存会话的方式，这在多节点环境下会导致会话丢失问题。

问题背景

传统实现中，StreamableHTTP 和 SSE 传输通过在服务器内存中缓存传输对象来实现状态保持。这种设计存在两个主要问题：

1. 单点故障风险：所有会话状态都存储在单个节点内存中，节点故障会导致会话中断
2. 扩展性限制：无法在负载均衡器后部署多个节点，除非使用粘性会话

技术挑战

实现真正的无状态服务需要考虑以下技术难点：

1. 连接状态序列化：HTTP 连接对象本身无法被序列化和存储
2. 消息重放机制：客户端重连时需要能够获取错过的消息
3. 会话恢复：新节点需要能够重建之前的会话状态

解决方案

1. 完全无状态模式

StreamableHTTP 传输支持完全无状态的操作模式，这种模式下：

• 每个请求都会创建新的传输实例
• 不依赖会话ID进行状态保持
• 适合简单请求-响应场景

// 无状态服务器示例
const server = express();
server.post('/mcp', async (req, res) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined, // 不使用会话ID
    enableJsonResponse: true
  });
  await transport.handleRequest(req, res);
});

2. 基于外部存储的状态管理

对于需要保持状态的场景，可以采用以下架构：

1. 状态序列化：将可序列化的会话状态存储在Redis等分布式缓存中
2. 事件存储：使用EventStore记录所有事件，支持消息重放
3. 状态恢复：通过会话ID从缓存重建传输状态

interface TransportState {
  sessionId: string;
  started: boolean;
  initialized: boolean;
  requestMappings: [string, string][];
}

// 状态序列化方法
public serialize(): TransportState {
  return {
    sessionId: this.sessionId,
    started: this._started,
    initialized: this._initialized,
    requestMappings: Array.from(this._requestToStreamMapping.entries())
  };
}

// 状态恢复方法
public static deserialize(state: TransportState, options: TransportOptions) {
  const transport = new StreamableHTTPServerTransport(options);
  // 恢复状态...
  return transport;
}

实现建议

1. 选择合适的模式：根据业务需求决定使用无状态还是有状态方案
2. 客户端适配：无状态模式下客户端需要处理可能的连接重建
3. 消息可靠性：使用EventStore确保消息不丢失
4. 性能考量：频繁的状态序列化/反序列化可能影响性能

最佳实践

1. 简单场景：优先考虑无状态实现，简化架构
2. 复杂场景：结合Redis和EventStore实现可靠的有状态服务
3. 客户端设计：实现自动重连和消息重传机制
4. 监控：对会话状态和消息流进行详细监控

结论

ModelContextProtocol TypeScript SDK 提供了灵活的传输实现方案，既支持简单的无状态模式，也支持基于外部存储的有状态方案。开发者应根据具体业务场景和可靠性需求选择合适的实现方式。对于大多数生产环境，推荐使用Redis存储会话状态的混合方案，在保证可靠性的同时获得水平扩展能力。

通过合理的架构设计，我们可以在分布式环境中实现可靠的上下文协议通信，同时保持服务的弹性和可扩展性。