高并发消息队列常用通知机制
Posted 马哥Linux运维
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高并发消息队列常用通知机制相关的知识,希望对你有一定的参考价值。
从朋友圈进来的各位大侠:
快猛点↑顶部蓝字「 马哥linux运维 」关注我们
想要了解更多资讯,请加入马哥教育官方群:169777636
高并发消息队列常用通知机制
最近在研究一个高性能的无锁共享内存消息队列,使用的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方式实现比较复杂。
上面这几种方式的共性是都需要陷入内核,被通知进程只有在内核态才能接收通知,对于处理性能要求高的场景,应该少用通知。所以,当然就看业务场景发送通知的开销是不是很大了。如果请求量很大,读进程一直忙于处理,不会频繁触发通知,那就很合适了。
点击【阅读原文】更精彩!
以上是关于高并发消息队列常用通知机制的主要内容,如果未能解决你的问题,请参考以下文章