干.NET做过几年的人多半迟早会碰到一件事机器上有几个进程需要把数据飞速地丢来丢去。进程间传输实时指标、业务事件、缓存变更通知频率一高文件轮询、数据库直连、普通RPC全都成了瓶颈。同时还要考虑锁竞争、序列化开销、连接断开后的恢复。这个话题看起来简单实际坑特别多。我把自己在.NET环境下做跨进程、高频率读写数据的常用方案和踩过的坑整理成一篇完整的实践记录涵盖命名管道、共享内存、互斥锁、事件通知、压测方式等给同样在选型和落地的朋友做个参考。1. 先拆需求所谓“高频读写”到底意味着什么1.1 高频场景的常见形态跨进程、高频率读写数据通常出现在两类场景里一类是主进程向辅助进程“喂”数据比如采集端给分析端发实时指标每秒发几千到几万条另一类是多个进程之间相互共享状态比如分布式缓存节点的本地内存同步、配置中心的变更广播。这类需求有个共同点单条消息体积不大从几十字节到几KB不等但条数非常多而且要求尽量低的延迟。和传统业务接口不太一样高频读写场景里每多一次拷贝、多一次锁、多一次序列化实际损耗都会被放大。所以选型不能只盯“能通”要看“能在多少频率下还能通”。1.2 本地跨进程与网络跨节点的本质差异同样是跨进程通信单机多进程和跨机器网络通信是两码事。单机场景下数据不需要经过真实网卡延迟主要由用户态到内核态的切换、协议栈处理、锁竞争和内存拷贝组成。跨机器场景还要加网络延迟、丢包重传、证书校验、防火墙策略等问题。很多热点讨论里提到的net::err_connection_reset、net::err_http2_protocol_error这类错误其实更多发生在远程访问场景。单机多进程如果用命名管道或共享内存一般碰不到这些网络协议错误但会碰到管道连接被重置、事件信号丢失、共享内存访问越界等本地化问题。所以本文讨论的重点会放在单机多进程最后再稍微提一下跨机器的扩展方式避免把两类问题混在一起。2. 方案选型命名管道、共享内存还是Socket2.1 命名管道最稳妥的起步方案.NET里做跨进程通信我最先推荐的其实是命名管道也就是NamedPipeServerStream和NamedPipeClientStream。它不是性能最好的但综合开发成本、稳定性、跨平台能力来看是性价比很高的选择。命名管道的优势在于使用体验接近IO流底层又是内核级IPC本机传输延迟比TCP走回环要低。管道还支持消息模式可以设置一条消息的边界虽然没有网络协议的粘包问题但二进制消息解析仍然要自己做好。高频写入时命名管道容易踩的坑包括客户端非正常退出导致服务端写入抛异常、异步读写回调里抛异常导致进程崩溃、多个线程同时往管道流写数据时数据交错。后面第五节我会专门讲这些问题。2.2 内存映射文件性能天花板如果命名管道压测撑不住或者数据量已经大到每秒几十万条就该考虑用MemoryMappedFile内存映射文件。它把一块文件或一块Pagefile-backed内存映射到进程地址空间多个进程可以共享同一块物理内存读写就是直接访问内存几乎不需要内核协议栈参与所以延迟最低、吞吐最高。但共享内存没有内建的消息边界和同步机制所有消息格式、写指针、读指针、生产者消费者关系都要自己设计。高频场景下通常配合环形缓冲区RingBuffer和命名事件来工作写进程只追加数据并更新写偏移读进程通过事件通知来消费。这块实现难度比命名管道高不少但只要写好了稳定性非常可观。2.3 TCP、UDP和文件共享的取舍不少朋友会习惯性地用TCP回环地址127.0.0.1来做本机通信认为socket更通用。回环TCP确实可行但延迟和上下文切换开销比命名管道高还要处理粘包、半包、连接异常重连实际开发成本不低。UDP虽然更快但丢包后要自己做应用层确认高频场景下等于把可靠传输重新发明一遍。文件共享则更不适合高频。用FileStream反复写同一个文件然后另一个进程轮询文件变化这个方案在每秒几十次的时候还勉强能用到每秒几百上千次时磁盘IO和文件锁竞争会直接拖垮整个系统。文件方案更适合低频配置同步不适合高频数据通道。2.4 选型决策参考表我把几个常用方案在高频场景下的表现整理了一下方便对比方案单机延迟相对吞吐开发成本可靠性适用频率文件轮询高毫秒级很低低中每秒几十次以内TCP回环中中中高高每秒几千次命名管道低高中高每秒几万次共享内存环形缓冲极低很高很高中高每秒几十万次以上个人建议千万别一上来就追求“最强方案”先用命名管道把业务跑通压测后再考虑要不要换共享内存。很多需求其实每秒几千条命名管道已经能轻松覆盖。3. 实操用命名管道搭一条高频数据传输通道3.1 服务端管道创建与消息读取循环先看最简单的服务端代码。这里我以.NET 6为基准用异步方式创建命名管道服务。using System.IO.Pipes; var pipeServer new NamedPipeServerStream( demo-pipe, PipeDirection.InOut, 4, PipeTransmissionMode.Byte, PipeOptions.Asynchronous); await pipeServer.WaitForConnectionAsync(); Console.WriteLine(客户端已连接); byte[] buffer new byte[4096]; while (true) { int read await pipeServer.ReadAsync(buffer, 0, buffer.Length); if (read 0) break; // 这里处理接收到的数据 ProcessMessage(buffer.AsSpan(0, read)); }这里面有两个关键选择需要解释。第一个是PipeDirection.InOut表示管道支持双向读写。如果数据流是单向的建议尽量用In或Out因为双向管道会额外引入同步成本而且容易在使用不当的时候产生死锁。第二个是PipeTransmissionMode.Byte按字节流模式读取。还有一个Message模式可以帮你把消息边界切好但Message模式下单条消息长度受操作系统限制而且读写时要注意IsMessageComplete判断处理起来不如字节流加自定义包头直观。高频场景里我更推荐字节流模式配合“4字节长度头消息体”的协议。这样读取时先读长度头再读对应长度的消息体可以避免半包问题也能天然支持单条消息超过管道默认消息长度限制。3.2 客户端高频写入的实现要点客户端相对简单但高频写入有很多细节不能省。using System.IO.Pipes; var pipeClient new NamedPipeClientStream(., demo-pipe, PipeDirection.InOut, PipeOptions.Asynchronous); await pipeClient.ConnectAsync(3000); Console.WriteLine(已连接到服务端); byte[] message new byte[] { 0x01, 0x02, 0x03, 0x04 }; await pipeClient.WriteAsync(message, 0, message.Length); await pipeClient.FlushAsync();这段代码看起来没问题但高频循环里如果每条消息都执行一次WriteAsync和FlushAsync每秒几万次调用会产生巨大的系统调用开销。正确的做法是批量写入把多条消息先拼到一个大的byte[]里再一次写入。比如攒够100条或等2毫秒再刷新一次吞吐能提升一个数量级。另外要特别注意的是命名管道的Stream不是线程安全的。如果多个生产者线程同时往同一个PipeClientStream写必须加锁或者把写操作串行化到单独的一个发送线程里。我更喜欢后者内部用一个Channelbyte[]队列业务线程只负责入队发送线程专注从队列取出并写入管道既避免锁竞争又天然做了流量缓冲。3.3 不要把全部精力浪费在JSON序列化上高频读写场景里序列化往往是第一瓶颈。有人用JsonSerializer在每秒几千条消息的管道上跑CPU直接被打满。二进制协议才是高频场景下的正确方向。我目前用得比较多的是MemoryPack它比传统二进制序列化更快零拷贝处理做得也更好。以MemoryPack为例using MemoryPack; [MemoryPackable] public partial class MetricData { public long Timestamp; public string MetricName; public double Value; } byte[] payload MemoryPackSerializer.Serialize(new MetricData { Timestamp DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(), MetricName cpu_usage, Value 42.5 });MemoryPack支持直接序列化到现有buffer的片段可以和前面提到的“长度头消息体”协议完美配合先预留4字节长度序列化到长度头之后的位置最后回填长度。这样可以减少一次数据拷贝高频场景下非常值。如果你的团队不希望引入额外增量编译依赖也可以直接用BinaryWriter手写紧凑二进制只是字段多了以后维护成本会高。总之原则只有一个高频传输通道上不要用文本型序列化。4. 跨进程锁与信号同步的工程细节4.1 命名Mutex一定不能用来做高频读写锁搜索热词里有CreateMutex确实跨进程互斥锁往往第一反应就是命名Mutex。它的作用是让多个进程能按名字访问同一个内核互斥体防止不同进程同时进入临界区。比如防止同一个服务被启动多次或者两个进程同时写同一个资源。但是命名Mutex不适合放在高频读写路径里。每次WaitOne到ReleaseMutex是一次完整的内核模式切换在高频操作中这个损耗会被放大可能一次切换耗时从几十微秒到几百微秒不等和共享内存本身微秒级的访问速度完全不匹配。我见过一个项目用Mutex锁保护内存映射文件的写入结果频率一上万直接把延迟拉高了几十倍。正确用法是只在进程启动阶段用命名Mutex判断单实例或者只在低频、低代价的资源抢占里使用。高频数据通道里的并发控制应该采用读写锁、自旋锁或无锁设计。4.2 用EventWaitHandle做高频信号通知如果你用了共享内存映射文件那么生产者写好消息后消费者怎么知道“有数据来了”比较自然的做法是用EventWaitHandle它也是命名内核对象可以在进程间通过名称共享。var readyEvent new EventWaitHandle(false, EventResetMode.AutoReset, demo-pipe-data-ready);生产者写入数据后调用readyEvent.Set()消费者调用readyEvent.WaitOne()等待信号。AutoReset模式会让消费者等待一次后自动复位正好对应“一条消息来一次通知”。这种方案比消费者进程轮询共享内存高效得多因为轮询会白白空转CPU。但要注意Set()和WaitOne()是内核调用本身也有开销所以如果每秒几十万条每次都发一次内核事件信号反而会成为瓶颈。常见优化是消费者把WaitOne(0)和短暂Thread.Sleep轮询结合或者走“批处理通知”路线每收集一批数据才发一次信号。这需要根据实测数据来定。4.3 ReaderWriterLockSlim和内存屏障的选择对于高频写、中低频读的场景可以用ReaderWriterLockSlim保护共享内存区域。它允许多个读线程并发写线程独占比全量锁好很多。但前提是读锁和写锁的时间都足够短否则会被写者饥饿问题影响。如果频率再往上走就要考虑无锁化。比较常用的方案是Interlocked操作配合内存屏障比如更新一个共享的写入偏移量时使用Interlocked.Exchange(ref offset, newValue)确保其他进程能看到最新值。还需注意volatile关键字和内存屏障在跨进程场景里只能解决单进程内的可见性问题对于映射到进程地址空间的共享内存Interlocked系列操作在很多平台上能保证原子性但强烈建议做个多进程压测因为CPU内存模型在不同架构上有差异。5. 高频写入的避坑指南与性能调优5.1 缓冲区大小、背压和流量控制命名管道创建时有个maxByteCount参数也就是NamedPipeServerStream构造器里的maxBufferSize需要按业务单条消息大小和瞬时突发量来设置。设太小缓冲区满了后会阻塞读写甚至抛异常设太大占用的内核缓冲内存也不少要考虑并发管道数量。高频场景下更关键的是背压控制。当生产者的生产速度远大于消费者的消费速度管道缓冲区会堆积最终导致生产者写入阻塞。如果使用Channel做生产队列同样会有队列无限增大的风险。正确的做法是利用信号量或Channel的BoundedCapacity控制队列大小队列满时选择丢弃旧消息或让生产者短暂等待避免内存被耗尽。实时性要求高、对丢数据敏感度低的场景可以保留最新消息丢弃旧消息这种策略实现起来也最简单。5.2 常见连接异常和处理经验高频写入时最典型的异常是IOException: Pipe is broken。这通常发生在对端进程退出或崩溃的情况下。服务端或客户端在ReadAsync里读到0或者WriteAsync抛异常都必须第一时间释放旧管道实例然后重新进入连接循环。还有一类问题容易被忽略客户端连续ConnectAsync失败。如果服务端进程还没起来客户端会一直重试重试间隔不宜过短否则会堆积大量线程最好用指数退避策略。另外在高频写入时如果服务端处理过慢客户端会阻塞在WriteAsync上这时要小心不要在阻塞的IO线程上等待其他锁否则容易形成等待链。我自己的做法是写一个PipeReconnectHelper把建连、断线重连、写超时都封装好。每次IO操作都放进CancellationTokenSource一旦对端未响应超过预定时间强制取消并重建连接。这样整个管道通道在对方进程重启后能自动恢复。5.3 权限、命名冲突与多实例的问题命名管道和命名事件都依赖操作系统级命名空间所以命名冲突是个真实存在的坑。如果你误用了和系统或其他程序相同的管道名可能在启动时就抛异常。建议统一加项目级前缀比如yourproduct_pipe_xxx、yourproduct_event_xxx。权限问题也不能忽视。默认管道访问权限允许同一登录会话的进程连接但如果跨用户运行可能连接失败。Windows下可以通过PipeSecurity设置访问规则Linux下则要注意账号权限确保运行进程的用户对管道有访问权。命名Mutex还有一个特殊异常AbandonedMutexException。当持有Mutex的进程在未释放的情况下崩溃其他进程等待时会收到自己被授予所有权的同时伴随该异常。这是正常信号可以继续执行但不能当作普通异常忽略。要在全局异常处理里单独区分。5.4 压测工具怎么写才有参考价值最后说下压测方法。不要用调试环境里的随手测试要写一个独立的小工具模拟真实消息体积和频率。核心思路是固定消息大小比如256字节、1KB、4KB记录发送N条消息的总耗时、平均单条耗时、P99延迟。var sw Stopwatch.StartNew(); for (int i 0; i totalCount; i) { // 写入一条消息注意模拟真实场景下的大小 } sw.Stop(); var throughput totalCount / sw.Elapsed.TotalSeconds; var avgLatency sw.Elapsed.TotalMilliseconds / totalCount;压测时有个容易被忽略的因素统计数据本身会产生CPU竞争。建议压测工具里先预热几百条消息再开始计时同时把计时器和业务线程分开避免Stopwatch的GetTimestamp()调用和管道写入互相干扰。测试结果至少要跑三组取中位数因为操作系统调度和后台线程都会造成抖动。6. 不同运行环境下的差异与升级选择6.1 .NET Framework 与 .NET 6/8 的差异如果你的项目还在.NET Framework 4.8上命名管道API也是可用的但异步模型相对老旧。BeginWrite/EndWrite这种编程模式写起来容易出回调地狱异常处理也更麻烦。而且.NET Framework在Unix系统上没有官方支持跨平台就要另想办法。升到.NET 6以后管道API改为统一基于ValueTask的异步模型配合Memory和Span可以大幅度减少缓冲区的分配和拷贝。这里我建议至少要升级到.NET 6如果业务已经跑在.NET Framework且短期不便迁移那就要特别注意GC频率高效利用大缓冲区避免巨型数组反复创建。6.2 Linux下的行为和Windows有区别跨进程高频率读写数据这个需求在多平台上越来越常见但很多人在Windows上写好的代码拿到Linux就跑不出一半性能。原因在于Linux下的命名管道虽然也叫管道但它的内建缓冲和Windows命名管道不同且没有命名管道那种基于文件共享的访问模式。在Linux上做单机跨进程高频通信我更推荐直接使用共享内存。.NET的MemoryMappedFile在Linux上映射的是/dev/shm性能非常接近内存访问。如果使用管道要考虑管道缓冲大小和PipeReader的读取方式是否匹配避免逐字节读取造成巨大性能损耗。6.3 性能不够时如何平滑切换到共享内存方案如果命名管道在压测中达不到预期切换到共享内存时不必推翻所有业务代码。较好的做法是抽象一层ITransport接口命名管道和共享内存分别实现。业务侧只管发送ReadOnlyMemorybyte和订阅接收回调不再关心底层是管道还是内存映射。内存映射文件的具体实现有几个坑躲不掉映射文件的大小要提前固定比如1GB写入偏移和读取偏移要保存在映射区内容量快满时要能处理覆盖策略。我推荐用单生产者单消费者模型这样不需要复杂的多读多写锁。多生产者的场景尽量在业务内先合并为一条生产链路。切换到共享内存后最好在四核以上机器上验证因为无锁环形缓冲区高度依赖CPU缓存一致性不同核数下的表现差异会很大。7. 最后再分享两个小技巧我看不少人在跨进程传输自定义二进制数据时总是习惯为每个字段单独写序列化代码遇到字段变更就改两端。实际上在.NET生态里完全可以利用SourceGenerator自动生成序列化代码比如MemoryPack就是通过[MemoryPackable]让编译器生成高效的二进制序列化逻辑既避免手写又保留了性能。另一个技巧是不要忽略Windows上的“命名文件映射”持久化路径。如果共享内存映射到一个真实的临时文件内存在文件刷新时会附带磁盘IO成本而使用Pagefile-backed映射即MemoryMappedFile.CreateNew不指定文件路径则完全在内存中速度更快但进程全挂后数据不会保留。高频读写场景下我几乎总是选择不落盘的Pagefile-backed共享内存除非有崩溃后恢复的需求。跨进程、高频率读写数据不是一个能靠某个万能库一次性解决的问题。命名管道适合大多数场景共享内存适合极致性能锁和同步方式则决定了你在高负载下会不会崩。我在实际项目中通常都是先用命名管道跑通业务再用压测数据来判断有没有必要升级到共享内存。希望大家少走几个我踩过的坑一套方案就能稳定扛住它的高频场景。