最近在研究一个高性能的无锁共享内存消息队列，使用的fifo来通知。结合之前《基于管道通知的百万并发长连接server模型》文章，这里总结一下常用的通知机制。
常用的通知机制中比较典型的有以下几种：
1. signal
这种机制下，我们向被通知进程发送一个特殊的signal（比如SIGUSR1），这样正在睡眠的读进程就会被信号中断，然后醒来。
该方法的优点是：读进程不需要监听一个额外的eventfd，适合一些不方便使用eventfd的场景；另外，用户可以选择是使用实时信号（SIGRTMIN+1），还是使用非实时信号（SIGUSR1）。
该方法的缺点是：通知不实时。因为信号的检查只有在中断返回的时候才会进行，这个时间跟操作系统的HZ、jiffies有关。
2. socket
这种机制下，写进程往socket（domain socket）写一个字符，然后读进程通过epoll得到数据到达的通知。
3. fifo
这种机制跟socket类似，写进程往fifo中写一个字符，然后读进程通过epoll得到数据到达的通知。
4. pipe
跟2、3差不多。
5. eventfd/signalfd
跟前面差不多，不过是内核帮我们事先fifo、signal通知，只有比较新的内核版本才支持。这种方式存在的问题是需要在不同进程间传递句柄，非fork方式实现比较复杂。
上面这几种方式的共性是都需要陷入内核，被通知进程只有在内核态才能接收通知，对于处理性能要求高的场景，应该少用通知。所以，当然就看业务场景发送通知的开销是不是很大了。如果请求量很大，读进程一直忙于处理，不会频繁触发通知，那就很合适了。
您还没有登录,请您登录后再发表评论