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