如何看懂 OpenSandbox 沙箱自动续期ingress 网关 Redis 事件链路延长 TTL 的完整指南【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandboxOpenSandbox 是一个面向 AI Agent 的安全、快速、可扩展的沙箱运行时Sandbox runtime。它的自动续期Auto-Renew机制可以解决一个常见痛点当用户通过 ingress 网关持续访问沙箱内的服务IDE、Web 应用、浏览器等时沙箱却可能因 TTL 到期被回收导致会话中断。本文带你完整看懂这条「ingress 网关 → Redis → server」的自动续期事件链路以及 TTL 是如何被一步步延长的 为什么需要访问驱动的自动续期沙箱默认有过期时间TTL。在交互式场景下只要还有流量访问就说明沙箱是活跃的但 OpenSandbox 此前要求客户端显式调用POST /sandboxes/{id}/renew-expiration来续期这会带来两个问题会话被误杀流量一直活跃TTL 却到期了用户正在跑的 notebook 或 Web 服务戛然而止续期风暴如果每个请求都触发一次续期高 QPS 下会产生大量无意义的续期调用。因此官方设计了一条**受控的、尽力而为best-effort**的续期链路把有访问这个信号转成受控的续期动作。沙箱内运行浏览器/Web 服务的典型场景——正是自动续期要保护的交互式负载全景图一次请求如何触发 TTL 延长整条链路分为三步分别由 ingress 网关和 OpenSandbox server 两端完成ingress 网关在反代转发流量时顺手发布一条 renew-intent续期意图事件到 Redis不阻塞代理请求Redis List 队列作为缓冲带LPUSH写入、BRPOP消费隔离数据面的流量突发与控制面的续期执行server 消费 worker从队列弹出事件经过五道门检查后才真正执行续期调用把过期时间延长为now 每轮续期时长。核心思想访问流量代表活跃度但只有通过资格校验的事件才会产生真正的 renew 调用。沙箱生命周期与启动流程示意——自动续期正是作用于这个生命周期的过期环节第一步ingress 网关捕获访问并发布续期意图在 ingress 代理的ServeHTTP处理流程中一旦请求的目标沙箱解析成功就会非阻塞地调用PublishIntentClient -- Ingress/Gateway | -- publish renew-intent to Redis (sandbox_id, ts, route info) | v OpenSandbox Renew Worker关键实现细节源码见 redis.go客户端限流默认同一沙箱至少间隔 60 秒才发布一次 intentshouldSendIntent高 QPS 下不会每个请求都入队异步发布内部 4 个 worker 消费容量 8192 的 channelRedis 操作超时仅 5 秒发布失败只记日志并丢弃绝不影响代理转发队列长度保护LPUSH后紧跟LTRIM队列超过上限自动截断防止积压。每条 intent 是一条 JSON包含sandbox_id、observed_atRFC3339 时间戳、port、request_uri等字段结构定义在 intent.go。触发点位于 proxy.go。第二步Redis List 队列作为事件缓冲带ingress 与 server 之间刻意选择了最简单的Redis List而非 Stream/Kafka/NATS特性说明队列 key默认opensandbox:renew:intent写入LPUSHingress 侧可配LTRIM限长消费BRPOP阻塞弹出server 侧多 worker 竞争消费语义无 ack、无重投纯尽力而为用 Redis 而不是让 ingress 直接调 server 续期 API有四个好处背压隔离ingress 快速写、worker 按自己节奏处理、延迟保护代理路径不等待续期执行、多副本友好多个 server 实例竞争消费每条消息只被一个 worker 拿到、故障收敛server 短暂不健康时事件可短暂滞留队列。生产部署中ingress、server 与 Redis 共同构成续期链路的基础设施第三步server 端消费事件并通过五道门server 端由consumer_concurrency默认 8 个个 worker 执行BRPOP超时 5 秒消费逻辑位于 consumer.py。每条事件必须全部通过以下检查才会真正续期Opt-in 检查沙箱创建时通过extensions[access.renew.extend.seconds]显式声明了续期时长300–86400 秒状态检查沙箱必须是Running有效性检查new_expires_at now 续期时长且必须大于当前过期时间才调用续期 API冷却检查min_interval_seconds默认 60 秒内该沙箱没有成功续期过在途去重每个沙箱同时只允许一个续期任务多副本部署下用SET opensandbox:renew:lock:{sandbox_id} NX EX ttl分布式锁去重拿不到锁直接丢弃。任何一项不通过事件被确认并丢弃。这保证了即使某个沙箱的流量热得发烫续期频率也是有界的。三方握手如何开启这条链路自动续期默认关闭需要三个条件同时满足才生效server 侧开关根配置中[renew_intent]段设置enabled true并按需开启redis.enabled、配置redis.dsn、redis.queue_key见 config.py 与 configuration.mdingress 侧开关ingress 组件以--renew-intent-enabled、--renew-intent-redis-dsn、--renew-intent-queue-key、--renew-intent-min-interval等参数启动定义见 parser.go沙箱级声明创建沙箱时在extensions中给出续期时长例如access.renew.extend.seconds: 1800——既表示opt-in也定义每次成功续期延长 30 分钟。任何一项缺失访问事件都会被忽略。完整设计含测试计划、风险与回滚策略可阅读官方提案 OSEP-0009 自动续期设计文档。总结OpenSandbox 的自动续期用一条极简的ingress 发布 → Redis List 缓冲 → server 消费事件链路把有访问就续期这一朴素想法变成了工程上可控的机制客户端限流 队列截断从源头控制事件量Redis List 解耦数据面突发与控制面执行多副本天然友好五道门opt-in、状态、有效性、冷却、分布式去重锁确保续期调用有界、幂等、尽力而为。对交互式沙箱负载来说这意味着只要用户还在访问沙箱就会在策略约束下被持续续命会话不再因 TTL 到期而意外中断 ✅【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何看懂 OpenSandbox 沙箱自动续期：ingress 网关 + Redis 事件链路延长 TTL 的完整指南
如何看懂 OpenSandbox 沙箱自动续期ingress 网关 Redis 事件链路延长 TTL 的完整指南【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandboxOpenSandbox 是一个面向 AI Agent 的安全、快速、可扩展的沙箱运行时Sandbox runtime。它的自动续期Auto-Renew机制可以解决一个常见痛点当用户通过 ingress 网关持续访问沙箱内的服务IDE、Web 应用、浏览器等时沙箱却可能因 TTL 到期被回收导致会话中断。本文带你完整看懂这条「ingress 网关 → Redis → server」的自动续期事件链路以及 TTL 是如何被一步步延长的 为什么需要访问驱动的自动续期沙箱默认有过期时间TTL。在交互式场景下只要还有流量访问就说明沙箱是活跃的但 OpenSandbox 此前要求客户端显式调用POST /sandboxes/{id}/renew-expiration来续期这会带来两个问题会话被误杀流量一直活跃TTL 却到期了用户正在跑的 notebook 或 Web 服务戛然而止续期风暴如果每个请求都触发一次续期高 QPS 下会产生大量无意义的续期调用。因此官方设计了一条**受控的、尽力而为best-effort**的续期链路把有访问这个信号转成受控的续期动作。沙箱内运行浏览器/Web 服务的典型场景——正是自动续期要保护的交互式负载全景图一次请求如何触发 TTL 延长整条链路分为三步分别由 ingress 网关和 OpenSandbox server 两端完成ingress 网关在反代转发流量时顺手发布一条 renew-intent续期意图事件到 Redis不阻塞代理请求Redis List 队列作为缓冲带LPUSH写入、BRPOP消费隔离数据面的流量突发与控制面的续期执行server 消费 worker从队列弹出事件经过五道门检查后才真正执行续期调用把过期时间延长为now 每轮续期时长。核心思想访问流量代表活跃度但只有通过资格校验的事件才会产生真正的 renew 调用。沙箱生命周期与启动流程示意——自动续期正是作用于这个生命周期的过期环节第一步ingress 网关捕获访问并发布续期意图在 ingress 代理的ServeHTTP处理流程中一旦请求的目标沙箱解析成功就会非阻塞地调用PublishIntentClient -- Ingress/Gateway | -- publish renew-intent to Redis (sandbox_id, ts, route info) | v OpenSandbox Renew Worker关键实现细节源码见 redis.go客户端限流默认同一沙箱至少间隔 60 秒才发布一次 intentshouldSendIntent高 QPS 下不会每个请求都入队异步发布内部 4 个 worker 消费容量 8192 的 channelRedis 操作超时仅 5 秒发布失败只记日志并丢弃绝不影响代理转发队列长度保护LPUSH后紧跟LTRIM队列超过上限自动截断防止积压。每条 intent 是一条 JSON包含sandbox_id、observed_atRFC3339 时间戳、port、request_uri等字段结构定义在 intent.go。触发点位于 proxy.go。第二步Redis List 队列作为事件缓冲带ingress 与 server 之间刻意选择了最简单的Redis List而非 Stream/Kafka/NATS特性说明队列 key默认opensandbox:renew:intent写入LPUSHingress 侧可配LTRIM限长消费BRPOP阻塞弹出server 侧多 worker 竞争消费语义无 ack、无重投纯尽力而为用 Redis 而不是让 ingress 直接调 server 续期 API有四个好处背压隔离ingress 快速写、worker 按自己节奏处理、延迟保护代理路径不等待续期执行、多副本友好多个 server 实例竞争消费每条消息只被一个 worker 拿到、故障收敛server 短暂不健康时事件可短暂滞留队列。生产部署中ingress、server 与 Redis 共同构成续期链路的基础设施第三步server 端消费事件并通过五道门server 端由consumer_concurrency默认 8 个个 worker 执行BRPOP超时 5 秒消费逻辑位于 consumer.py。每条事件必须全部通过以下检查才会真正续期Opt-in 检查沙箱创建时通过extensions[access.renew.extend.seconds]显式声明了续期时长300–86400 秒状态检查沙箱必须是Running有效性检查new_expires_at now 续期时长且必须大于当前过期时间才调用续期 API冷却检查min_interval_seconds默认 60 秒内该沙箱没有成功续期过在途去重每个沙箱同时只允许一个续期任务多副本部署下用SET opensandbox:renew:lock:{sandbox_id} NX EX ttl分布式锁去重拿不到锁直接丢弃。任何一项不通过事件被确认并丢弃。这保证了即使某个沙箱的流量热得发烫续期频率也是有界的。三方握手如何开启这条链路自动续期默认关闭需要三个条件同时满足才生效server 侧开关根配置中[renew_intent]段设置enabled true并按需开启redis.enabled、配置redis.dsn、redis.queue_key见 config.py 与 configuration.mdingress 侧开关ingress 组件以--renew-intent-enabled、--renew-intent-redis-dsn、--renew-intent-queue-key、--renew-intent-min-interval等参数启动定义见 parser.go沙箱级声明创建沙箱时在extensions中给出续期时长例如access.renew.extend.seconds: 1800——既表示opt-in也定义每次成功续期延长 30 分钟。任何一项缺失访问事件都会被忽略。完整设计含测试计划、风险与回滚策略可阅读官方提案 OSEP-0009 自动续期设计文档。总结OpenSandbox 的自动续期用一条极简的ingress 发布 → Redis List 缓冲 → server 消费事件链路把有访问就续期这一朴素想法变成了工程上可控的机制客户端限流 队列截断从源头控制事件量Redis List 解耦数据面突发与控制面执行多副本天然友好五道门opt-in、状态、有效性、冷却、分布式去重锁确保续期调用有界、幂等、尽力而为。对交互式沙箱负载来说这意味着只要用户还在访问沙箱就会在策略约束下被持续续命会话不再因 TTL 到期而意外中断 ✅【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
