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

最近基于 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 传递通知信号更合适。

你可能感兴趣的:(探讨一下共享内存通信中的通知机制)