activeMQ指南针_Queue完整分析

在接触activeMQ的这一段时间里，我们还是保持开始对它的态度，它是个优秀的开源消息中间件。消息中间件是个非常重要的搭建企业应用系统的重要组件，我们在不断深入分析activeMQ的过程中，发现直到5.1这个版本，都还是存在不少问题，有些是很致命，但正因为如此，我们更加坚定了要全面掌握activeMQ，我们不想重新做“轮子”，但我们要具备在轮子坏了或不好用的情况下，要能独立解决碰到的这些问题。下面我们通过分析网友提出的一个典型的问题场景，来作为我们指南针计划的结束。

Queue作为activeMQ里面一个很重要的通讯方式，网友的场景如下：

测试queue持久化消息时，发送接收20W条消息。打开消息消费者，连上再断开，反复进行这步操作，能接收到消息，接收端有时候会阻塞，但不能完全接收完20W条消息。(其实5000条就会发生问题，不用20W这么多)

       相关背景知识：

       因为这是5.1版本的一个非常严重的bug，所以我们会比较详细的进行分析。(我们在最终解决问题后，上activeMQ官网上发现它最新的源码是解决了该问题的，但这并不影响这个问题的典型性)。下面我们将从3个方面来分析：Queue消息的接收和发送、内存使用机制、消息的审查(audit)、消息在文件中的存储机制。

l         Queue消息的接收和发送

 

Queue接收消息并发给需要的消费者，具体过程如下：

1．  Queue从消息生产者接收消息。

2．  Queue使用一个“存储指针”来接收这些消息。当内存有空闲区域时，“存储指针”把消息放到内存中，当内存不够时，则把消息们存入磁盘文件。

3．  当有活动的(active)的消息消费者时，Queue会首先把“存储指针”的内存中的消息送给消费者，当内存的消息被消费掉，则从磁盘文件中再读入其他的消息(出问题处)，直至消息都被消费掉了。

其中最关键的方法是Queue类里的doPageIn()。

 

l         内存使用机制

activeMQ为了适应企业级的365*24的使用，在内存使用方面非常慎重，任何消息只有在内存里有空闲区域时，才能放到内存里，之后才能发给消费者。当消息被消费者消耗掉了后，确认信息会发给activeMQ。Queue接收到这些确认消息后，会把那些被确认的消息所占用的内存释放掉。

 

l         消息的审查(audit)

为了防止消息的重复发送，activeMQ采用了一个审查机制，它负责审查某条消息是否重复。它是一个最近最久未使用算法(LRU)队列。每个队列元素它是一个bit数组，它的运行机制如下所示：

 

 

       消息是一个个按照顺序进入bit数组，具体算法answer = (index - firstIndex) / BitArray.LONG_SIZE，其中：

BitArray.LONG_SIZE是每个bit数组的大小。

Index是消息的编号。(它是按照+1顺序增加的)

firstIndex是整个LRU队列的首Index，这个值会经常变化，因为当达到LRU的上限时，老的一批就被清除了，firstIndex += BitArray.LONG_SIZE。(出问题处)

 

l         消息在文件中的存储机制

存放在文件中的消息，它们是按照如下方式进行组织的：

 

每个消息都知道它的上一个和下一个消息，当它自身被删除后，相应的关系会进行调整。

 

问题原因分析：

    因为activeMQ在编码实现的时候，原本的想法应该是这样的：

1．  从生产者接收消息，如果Queue有可用的内存就放在内存中，没有则存入文件中。

2．  Queue发送消息给消费者时，先发送已经保存在内存中的消息。

3．  当内存中消息发送完后，顺序读入(这里是关键)文件中的消息，通过消息的审查机制，确认不是重复消息，则放入内存中供后续操作使用。

但是activeMQ5.1版本的实现，问题就出在第三步的顺序读入。因为从文件中读入它有个先决条件，那就是必须要有可用的内存，如果没有可用的话，就放弃本次消息读入，并且应该放弃这次读取操作。但是5.1版本是继续往下读，这就导致顺序错乱，使得当内存可用的时候，读入的消息在进行审查的时候，发生错误，错误认为它们是重复消息。这就导致发送20W条消息，不能保证完全收到。

 

解决方案：

类KahaReferenceStore的方法recoverNextMessages里的

if (entry != null) {

                int count = 0;

                do {

                    ReferenceRecord msg = messageContainer.getValue(entry);

                    if (msg != null ) {

                        if ( recoverReference(listener, msg)) {

                            count++;

                            lastBatchId = msg.getMessageId();

                        }

                    } else {

                        lastBatchId = null;

                    }

                    batchEntry = entry;

                    entry = messageContainer.getNext(entry);

                } while (entry != null && count < maxReturned && listener.hasSpace());

            }

 

改为

         if (entry != null) {

                int count = 0;

                do {

                    ReferenceRecord msg = messageContainer.getValue(entry);

                    testTheNextMsgId(msg.getMessageId().toString());

                    if (msg != null )

                    {

                        if ( recoverReference(listener, msg))

                        {

                            count++;

                            lastBatchId = msg.getMessageId();

                            batchEntry = entry;

                            entry = messageContainer.getNext(entry);

                        }

                        else

                        {

                           break;

                        }

                    }

                    else

                    {

                        lastBatchId = null;

                        batchEntry = entry;

                        entry = messageContainer.getNext(entry);

                    }

                } while (entry != null && count < maxReturned && listener.hasSpace());

            }

 

 

activeMQ指南针计划的结束，但它又是个新开始，我们通过这个计划收获了我们想要的东西了，同时我们不仅为各位朋友答疑解疑，也提供了activemqSpanner这个工具作为消息网络拓扑图工具。再一次感谢各位朋友对我们的信任。

        现在，我们正式启动activeMQ笑脸计划。它的目的不再是给大家提供解决问题的方向，而是直接解决大家碰到的各种问题，给大家带去笑脸。它将是一个长期坚持的事情，任何关于activeMQ使用过程的疑惑、问题、bug、功能改进，都可以在这个计划里交流。所有在笑脸计划中提出的问题、功能改进、解决方案，都将完全通过网络无偿分享给所有人。

如果发现了ActiveMQ的bug， 可以直接报 JIRA 并提交你的patch。
这样的笑脸工程会让更多人受益。

ReferenceRecord msg = messageContainer.getValue(entry);
testTheNextMsgId(msg.getMessageId().toString());
if (msg != null ){
...
}
else
{
break;
}

你这样写我觉得是有问题的;
msg==null情况呢?

我对MQ不是很了解,但我觉得"如果没有可用的话，就放弃本次消息读入",这个内存检测应该在messageContainer.getValue()方法之前或之中要做的吧,如果内存不够返回的msg应该会为null吧?

-关于传输是否连续的问题;

我觉得牵涉到网络传输的东西,作为中间件产品,不保证连续性是否更好?
这个工作给应用来处理是否性能更佳?