最近在研究一個高性能的無鎖共享內存消息隊列，使用的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方式實現比較復雜。
上面這幾種方式的共性是都需要陷入內核，被通知進程只有在內核態才能接收通知，對於處理性能要求高的場景，應該少用通知。所以，當然就看業務場景發送通知的開銷是不是很大了。如果請求量很大，讀進程一直忙於處理，不會頻繁觸發通知，那就很合適了。