RocketMQ学习笔记——长轮询和消息存储
长轮询
Consumer从消息队列获取消息的方式主要有两种:pull和push。两种都有一些问题,比如说pull的情况下,有时候可能导致消息在服务端堆积,消息处理延时较高,有时候又可能因为消息队列中没有消息而导致空拉取,造成资源浪费,而在push的情况下,可能导致超出客户端压力,造成客户端卡死甚至宕机。于是,把pull和push相结合,得到了长轮询。长轮询的机制是由客户端发起pull请求,服务端接收到客户端的请求后,如果发现队列中没有消息,并不立即返回,而是持有该请求一段时间,在此期间,服务端不断轮询队列中是否有新消息,如果有,则用现有连接将消息返回给客户端,如果一段时间内还是没有新消息,则返回空。长轮询机制的好处在于,其本质还是pull,所以,消息处理的主动权还是在客户端手中,客户端就可以根据自己的能力去做消息处理。而服务端持有请求一段时间的机制又很大程序的避免了空拉取,减少了资源的浪费。但是,这种机制也有一定问题,当客户端数量过多时,服务端可能在时间段内需要持有过多的连接,这种请求下,也会对服务端造成压力。不过,一般来说,消息队列的承压能力还是比较可靠的,再加上集群的保障,基本不用担心这个问题。
消息存储
消息在MQ中间件中,需要基于某种介质存储起来。会是直接堆积在内存中吗?不可能,一是消息的量如果是万级,亿级甚至更大,内存中可能放不下,二是要考虑一个消息中间件宕机重启后消息如何恢复的问题。分析当前一些主流的MQ中间件,发现基本上有三种存储方式:
关系型数据库DB。非关系型数据库。本地文件系统。分析对比一下三种方式:
读写速度:这里,我们考察的是一个消息的整体读写速度。一般来讲,我们可能认为,通过网络把消息放到Redis中,可能会更快一些,接下来是关系型数据库,如MySQL,再然后是文件系统,这是因为文件系统涉及到IO。我们基于IO > 网络 > 内存 这样一个基本常识得到这个结论。但是,事实上,消息放到关系型或非关系型数据库后,还是要存储到磁盘中。所以,这种情况下,并不是省掉了IO,而是把IO交给了第三方。所以,综合来说,还是自己直接写文件系统来得快一些,这样省去了网络的开销。可靠性:既然依赖了第三方,那第三方的可靠性就直接影响到了自身。所以,我们认为,从这个角度来说,还是自己进行文件读写的可靠性要高一些。实现复杂度:自己实现一个文件系统的消息读写显然是要比直接依赖第三方复杂,不然,大家都自己实现一个就好了,何必依赖第三方呢?page cache
RocketMQ采用的是本地文件的形式来存储消息,在这种模式下,如何高效的进行磁盘IO就成为了RocketMQ必须去研究的一个课题。在这个过程中,有许多重要的角色,其中之一,比如说page cache。page cache,又称之为Pcache,中文名称为页高速缓冲存储器,简称页高缓。它是Linux系统专门为提高文件访问速度而设计的。关于page cache的细节我们暂时并不打算深入讨论,暂时只需要知道的是,充分利用page cache,可以大大提高磁盘IO的性能。
mmap
mmap是一种内存映射文件的方法,通过在进程地址空间中,建立与文件磁盘地址的映射关系,以达到不需要通过read、write等系统函数就可以读写文件的目的,同时,也实现了在不同进程间进行文件的共享。
NIO
NIO是由jdk 1.4以上版本提供的一种全新的IO方式,它的原来的IO的区别主要有两点:
IO是面向流的,NIO是面向块的。IO是阻塞式的,NIO是非阻塞的。noop
noop是一种输入输出的高度算法,又称为电梯高度算法,简单来说,就是把输入输出请求都放到一个FIFO队列中,然后按次序执行队列中的输入输出请求。
RocketMQ存储架构
图片转载自 https://www.jianshu.com/p/b73fdd893f98下篇我们来聊这张图里的更多内容。