探讨一下共享内存通信中的通知机制

最近基于 Aeron 实现了一下 Service Mesh Sidecar 的本地通信，但是在 IdleStrategy 上犯了难，无论怎么选都感觉不合适，这几天跟大数据部门写 C++ 的同学聊了一下，一句话帮我解开了难题，不得不感慨一下：虽然一直不认为自己是一个 CURD boy，但是看起来也没有高明多少（尴尬......）。

这篇文章简单总结了一下我遇到的问题，简而言之，就是在 Aeron 共享内存通信的场景下，如何告诉对端进程有新消息可读了，而不是让对端进程一直在轮询检查。

0.

首先解释一下，何为共享内存通信中的通知机制？

以 Aeron 的 Conductor 通信为例：

（如果你不了解 Aeron 也没关系，重点关注读取数据那部分，想要详细了解可以参考我之前的文章。）

Aeron 实现了一个很优秀的无锁轮询算法：

1. 「写入者」先在 length 字段写入一个负值，然后写入消息体，最后再更新 length 字段；
2. 「读取者」轮询 length 字段，如果是正值，那就表示有待读取的消息。

Aeron 是通过控制 length 字段，结合轮询机制，实现了通知机制。

简而言之，本文要探讨的通知机制就是：「写入者」如何告诉「读取者」有新的数据可读。

这是个比较细节的问题，对于一个 Java 开发来说，你可能根本就不会认为这是个问题，比如说网络通信，我们用 Netty 就好，追问一句 Netty 的 reactor 模型是如何实现的？答：基于 epoll 的事件通知。至于通知事件是如何产生的，这可能就没人关心了，因为这是内核里的逻辑了。

当然，我们用共享内存机制就是想跳出内核，实现一个轻量的高性能的通信方式，所以也不会亦步亦趋的照搬内核的逻辑，但是掌握 epoll 的通知机制非常有助于理解通知机制中的 tradeoff。

1. epoll 通知机制

epoll 是一个非常优秀的事件通知机制。

总体来看，调用 epoll_wait 时，如果有就绪的 fds，那么直接返回；如果没有，那么主动让出 CPU，阻塞等待。等到有 fd 就绪的时候，会回调等待队列中注册的 ep_poll_callback 函数，更新就绪列表，然后唤醒线程，返回结果。

优秀！如果持续有就绪事件，以轮询的模式运行，不需要切换线程；如果没有就绪事件，会让出 CPU，等待回调，不至于浪费资源。

epoll 的核心就是等待队列的回调机制，因为就绪列表的设置都是在这个回调中完成，另外还做了阻塞时的唤醒操作。

上图以 socket 为例，展示了 socket 文件的等待队列，以及与 epitem 的关联关系。

对于 TCP 网络的场景，再深入一下，我们看一下 ep_poll_callback 回调是如何执行的。换句话说，这里想再了解一下 Linux 内核对于网络包接收的通知机制。

在之前的文章中，我用 debug 的方式查看过 ep_poll_callback 的调用栈，再结合理论知识，其实不难理解整体的过程。（当然细节很多，短时间不太可能完整理解）

首先网卡收包是一个硬中断：

然后是软中断（debug 的调用栈主要展示的就是这个过程）：

主干流程很清晰，软中断执行线程一路调用，最终在 sock_def_readable 方法中回调了 socket 等待队列中注册的 func，也就是 epoll_ctl 时注册的 ep_poll_callback。

其中有个细节很有意思，软中断处理函数 net_rx_action 第一步操作是通过 napi_poll 继续收包，而不是立即交付数据，继续响应中断。

收到中断，改为轮询，达到条件再退回到等待中断，这个设计很巧妙，既减少中断的频次，又避免了单纯轮询对 CPU 资源的浪费。

2. 共享内存通信的通知机制

2.1 semaphore

由于刚接触共享内存通信就站在了 Martin Thompson 这位巨人的肩膀上，最近从头学了一下 man7/tlpi 才意识到一个事情，通常来说两个进程同时操作一块内存区域是需要加锁的，Aeron 这种无锁的算法实际上是一种很高级的方式。

如果不用这种无锁的方式，那么可以使用 POSIX semaphores，既处理了并发操作，又提供了通知机制。

2.2 epoll 通知 + 轮询

既然 Aeron 已经提供了无锁的实现，再退回到 semaphore 同步就不太合适了。

参考内核处理网络收包的方式，同时又利用好内核提供的基础设施，那么可以这样来实现通知机制。

使用 named pipe 传递通知信号，「读取者」使用 epoll 监听 named pipe，如果有新的通知，那么转为轮询策略，读取共享内存中的数据，最后再退回到 epoll 等待新的通知。

既能尽可能快的处理新消息，又不至于将 CPU 资源都浪费在轮询上。

当然，可以用于传递的信号的基础设施有很多，这里选择 named pipe 原因是使用方式与 shm_open 这套 API 比较统一。关于各种共享内存的方式可以参考我上篇文章，如果已经使用了 memfd_create 的方式构建共享内存的话，那么用 eventfd 传递通知信号更合适。