IAsyncObserver.OnNextAsync 不会并发调用，因其由 StreamPullingAgent 单消费者拉取机制与 grain 单线程调度保证严格串行；需异步实现避免阻塞，否则导致流延迟堆积。
Orleans 的 IAsyncStream<T> 和 IAsyncObserver<T> 不是线程安全的并发模型，而是单线程、顺序交付的虚拟流抽象——所有事件按发布顺序、在 grain 或 observer 所属的逻辑上下文中串行处理。
为什么 IAsyncObserver.OnNextAsync 不会并发调用
Orleans 流设计强制“每订阅一个 observer，其 OnNextAsync 调用严格串行化”，即使底层有多个 producer 并发推送，或多个 silo 同时投递消息。这是由 StreamPullingAgent 的单消费者拉取机制 + grain 激活上下文的单线程调度保证的。
- 你无需加锁或手动同步
OnNextAsync内部状态（比如累加计数器、更新缓存） - 但这也意味着：如果某个
OnNextAsync执行耗时（如同步 DB 写入、阻塞 IO），整个流订阅将被阻塞，后续消息延迟堆积 - 错误示例：
public Task OnNextAsync(MyEvent e, StreamSequenceToken token = null) { // ❌ 危险：同步写数据库，阻塞流处理 _dbContext.Events.Add(e); _dbContext.SaveChanges(); // 阻塞线程，拖慢整个订阅 return Task.CompletedTask; } - 正确做法：始终用异步路径，让控制权及时交还调度器
public async Task OnNextAsync(MyEvent e, StreamSequenceToken token = null) { // ✅ 推荐：异步持久化，不阻塞 await _dbContext.Events.AddAsync(e); await _dbContext.SaveChangesAsync(); }
GetStream<T> 生成句柄是本地的，但流语义跨集群共享
调用 streamProvider.GetStream<T>(streamId) 只是创建一个轻量级、无网络开销的逻辑句柄；真正的流生命周期、消息路由、订阅管理由 Orleans 运行时在集群中协调。这意味着：
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
-
streamId必须全局唯一：靠StreamId.Create("namespace", guid)组合保证——guid建议来自 grain ID（如this.GetPrimaryKey()），namespace区分业务域（如"order-events"或"chat-messages"） - 同一
streamId在不同 silo 上调用GetStream，拿到的是指向同一个逻辑流的句柄，不是各自独立的副本 - Producer 和 Consumer 可以部署在完全不同的 silo 上，Orleans 自动完成消息投递和订阅发现（依赖配置的 pub/sub 存储，如
PubSubStore） - 常见坑：忘记在 silo 配置中启用流提供程序和 pub/sub 存储
// SiloBuilder 必须包含这两行 silo.AddMemoryStreams("SimpleStreamProvider") .AddMemoryGrainStorage("PubSubStore"); // 否则 SubscribeAsync 会静默失败或超时
背压不是自动的，得靠配置+代码配合
Orleans 默认不拒绝或缓冲过载消息；它依赖两种机制协同实现背压：LoadShedQueueFlowController（CPU 触发限流）和 BatchContainerBatchSize（控制每次拉取条数）。但它们都需显式开启。
- 默认情况下，
OnNextAsync调用会排队等待执行，没有上限——内存可能被撑爆 - 启用 CPU 背压：
options.LoadSheddingEnabled = true; options.LoadSheddingLimit = 0.8; // CPU > 80% 时暂停接收新消息
- 减小批处理大小降低内存压力（尤其对大消息流）：
services.Configure<StreamPullingAgentOptions>(opts => { opts.BatchContainerBatchSize = 1; // 默认是 1，设为 5 可提升吞吐但增加延迟 }); - 真正关键的背压点在 consumer 端代码里：别让
OnNextAsync成为瓶颈，该异步就异步，该降频就降频（比如用RegisterTimer批量消费）
最易被忽略的一点：流的“顺序性”只保证 per-subscription，不保证 per-producer 或全局全序。如果你从 3 个不同 grain 并发调用 stream.OnNextAsync，consumer 收到的顺序取决于网络延迟、silos 负载、pulling agent 调度时机——想强序，必须用同一个 grain 发送，或引入外部序列号+客户端排序逻辑。
