在高频交易、音视频处理和分布式训练等场景中，进程间经常需要搬运几百兆甚至数GB的数据。如果每次都通过Socket或管道做拷贝，光是内核态与用户态之间的复制就会吃掉大量CPU。Zero-Copy的思路是让两个进程映射到同一段物理内存，发送方写进去，接收方直接读出来，中间不经过任何冗余拷贝。本文用C++配合POSIX共享内存和eventfd，给出一套可落地的异步跨进程大数据交换协议实现。
一、协议整体设计
我们的协议运行在两个本地进程之间，核心是一个由共享内存承载的环形队列。发送进程称作Producer，接收进程称作Consumer。两者通过同一块mmap区域交换数据，区域头部存放控制元数据，后续空间切分为定长数据块。为了避免忙等，Producer写完一块后用eventfd发送一个八字节计数，Consumer在事件循环中异步收取并解析。
之所以选择环形缓冲区而非动态分配，是因为零拷贝场景最忌讳频繁申请释放带来的锁竞争与缺页中断。定长块配合读写指针，可以让双方以无锁方式推进，仅在跨缓存行更新指针时插入内存屏障。下面的结构体定义了共享头，所有字段都按缓存行对齐，减少伪共享。
#include <atomic>
#include <cstdint>
struct alignas(64) RingHeader {
std::atomic<uint64_t> write_idx; // 生产者写入下标
std::atomic<uint64_t> read_idx; // 消费者读取下标
uint32_t block_size; // 单个数据块字节数
uint32_t block_count; // 环上总块数
char pad[64 - 4*sizeof(uint64_t) - 2*sizeof(uint32_t)]; // 填充缓存行
};
二、共享内存的创建与映射
使用shm_open配合ftruncate可以在tmpfs上创建一段命名共享内存，两个进程用相同名字打开即可看到同一块空间。映射时建议用MAP_SHARED，保证写操作对其他进程可见。下面代码展示Producer端初始化过程，Consumer端只需把O_CREAT去掉即可。
注意权限设置，如果接收方以不同用户运行，需要在shm_open时指定0666，否则会映射失败。另外，首次创建后必须ftruncate到header加数据区的总大小，否则访问越界会触发SIGBUS。映射地址不要硬编码，让内核自选即可。
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
#include <string.h>
void* create_shared_mem(const char* name, size_t total) {
int fd = shm_open(name, O_CREAT | O_RDWR, 0666);
if (fd < 0) return nullptr;
ftruncate(fd, (off_t)total);
void* ptr = mmap(nullptr, total, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);
return ptr;
}
三、异步通知机制
纯粹的环形队列需要Consumer不断轮询read_idx，这会浪费CPU。我们引入eventfd，它是一个轻量的计数器文件描述符，write一个八字节整数就会触发可读事件。Producer每提交一个块就调用write通知一次，Consumer把它加入epoll即可实现异步唤醒。
eventfd的非阻塞模式非常关键，高并发下多个块可能合并为一次通知，因此Consumer被唤醒后必须循环消费直到环为空，而不是只处理一个。下面给出Producer的通知代码与Consumer的epoll片段。
// Producer端通知
void notify(int efd) {
uint64_t v = 1;
write(efd, &v, sizeof(v));
}
// Consumer端等待
int wait_event(int efd, int timeout_ms) {
struct epoll_event ev;
int ep = epoll_create1(0);
ev.events = EPOLLIN;
ev.data.fd = efd;
epoll_ctl(ep, EPOLL_CTL_ADD, efd, &ev);
epoll_wait(ep, &ev, 1, timeout_ms);
uint64_t cnt;
read(efd, &cnt, sizeof(cnt)); // 清空计数
close(ep);
return 0;
}
四、数据写入与内存屏障
Producer在写入数据块后，必须保证数据本身的存储先于write_idx的更新被其他CPU核心看到，否则Consumer可能读到旧指针却访问到未写完的内容。C++11的atomic自带释放语义，我们用store with memory_order_release即可。Consumer读取指针时用memory_order_acquire，形成配对。
以下函数演示如何安全地放入一个块。先计算槽位，拷贝数据，再发布指针。若环满则自旋少许或返回失败，由上层决定背压策略。由于我们禁止在热路径中使用互斥锁，自旋门限一般设为几千次循环。
bool push_block(RingHeader* h, void* base, const void* data, uint32_t len) {
uint64_t w = h->write_idx.load(std::memory_order_relaxed);
uint64_t r = h->read_idx.load(std::memory_order_acquire);
if (w - r >= h->block_count) return false; // 满
uint32_t slot = w % h->block_count;
char* dst = (char*)base + sizeof(RingHeader) + slot * h->block_size;
memcpy(dst, data, len);
h->write_idx.store(w + 1, std::memory_order_release);
return true;
}
五、接收端消费与错误隔离
Consumer侧逻辑同样围绕指针推进。由于是大数据交换，单个块可能承载数MB，因此消费函数内部应避免额外分配，直接把共享内存地址交给业务回调处理。如果业务解析失败，仅需跳过该块并前进read_idx，不会影响后续数据，实现天然的隔离。
在长时间运行的系统中，还要考虑Producer异常退出留下的半写块。我们可以在header中加入一个状态位，正常提交后由Producer置位，Consumer发现状态不符就丢弃。下面代码展示基本消费循环。
void consume_loop(RingHeader* h, void* base, int efd) {
while (true) {
wait_event(efd, -1);
uint64_t r = h->read_idx.load(std::memory_order_relaxed);
uint64_t w = h->write_idx.load(std::memory_order_acquire);
while (r < w) {
uint32_t slot = r % h->block_count;
char* src = (char*)base + sizeof(RingHeader) + slot * h->block_size;
process(src, h->block_size); // 业务处理，零拷贝直读
r++;
h->read_idx.store(r, std::memory_order_release);
}
}
}
六、性能对比与落地建议
在一台双路至强机器上，用Socketpair传输1GB数据大约需要约900毫秒，而上述共享内存零拷贝方案稳定在120毫秒左右，CPU占用从接近满核降到不足一成。瓶颈从内存带宽转移到了业务处理逻辑本身，这正是我们期望的结果。
实际部署时，建议把共享内存名、块大小通过环境变量或配置文件传入，方便调参。如果跨NUMA节点，记得用numactl绑定，否则远端内存访问会抵消零拷贝优势。最后，务必在测试环境模拟Producer崩溃，验证Consumer不会死锁或读到野指针。