[转载] activeMQ指南针_Queue完整分析

在接触activeMQ的这一段时间里，我们还是保持开始对它的态度，它是个优秀的开源消息中间件。消息中间件是个非常重要的搭建企业应用系统的重要组件，我们在不断深入分析activeMQ的过程中，发现直到5.1这个版本，都还是存在不少问题，有些是很致命，但正因为如此，我们更加坚定了要全面掌握activeMQ，我们不想重新做“轮子”，但我们要具备在轮子坏了或不好用的情况下，要能独立解决碰到的这些问题。下面我们通过分析网友提出的一个典型的问题场景，来作为我们指南针计划的结束。 Queue作为activeMQ里面一个很重要的通讯方式，网友的场景如下： 测试queue持久化消息时，发送接收20W条消息。打开消息消费者，连上再断开，反复进行这步操作，能接收到消息，接收端有时候会阻塞，但不能完全接收完20W条消息。(其实5000条就会发生问题，不用20W这么多)        相关背景知识：        因为这是5.1版本的一个非常严重的bug，所以我们会比较详细的进行分析。(我们在最终解决问题后，上activeMQ官网上发现它最新的源码是解决了该问题的，但这并不影响这个问题的典型性)。下面我们将从3个方面来分析：Queue消息的接收和发送、内存使用机制、消息的审查(audit)、消息在文件中的存储机制。 l Queue消息的接收和发送 2009-8-11 09:22 上传 下载附件 (21.81 KB) Queue接收消息并发给需要的消费者，具体过程如下： 1． Queue从消息生产者接收消息。 2． Queue使用一个“存储指针”来接收这些消息。当内存有空闲区域时，“存储指针”把消息放到内存中，当内存不够时，则把消息们存入磁盘文件。 3． 当有活动的(active)的消息消费者时，Queue会首先把“存储指针”的内存中的消息送给消费者，当内存的消息被消费掉，则从磁盘文件中再读入其他的消息(出问题处)，直至消息都被消费掉了。 其中最关键的方法是Queue类里的doPageIn()。 l 内存使用机制 activeMQ为了适应企业级的365*24的使用，在内存使用方面非常慎重，任何消息只有在内存里有空闲区域时，才能放到内存里，之后才能发给消费者。当消息被消费者消耗掉了后，确认信息会发给activeMQ。Queue接收到这些确认消息后，会把那些被确认的消息所占用的内存释放掉。 l 消息的审查(audit) 为了防止消息的重复发送，activeMQ采用了一个审查机制，它负责审查某条消息是否重复。它是一个最近最久未使用算法(LRU)队列。每个队列元素它是一个bit数组，它的运行机制如下所示： 2009-8-11 09:22 上传 下载附件 (15.24 KB)        消息是一个个按照顺序进入bit数组，具体算法answer = (index - firstIndex) / BitArray.LONG_SIZE，其中： BitArray.LONG_SIZE是每个bit数组的大小。 Index是消息的编号。(它是按照+1顺序增加的) firstIndex是整个LRU队列的首Index，这个值会经常变化，因为当达到LRU的上限时，老的一批就被清除了，firstIndex += BitArray.LONG_SIZE。(出问题处) l 消息在文件中的存储机制 存放在文件中的消息，它们是按照如下方式进行组织的： 2009-8-11 09:22 上传 下载附件 (9.63 KB) 每个消息都知道它的上一个和下一个消息，当它自身被删除后，相应的关系会进行调整。 问题原因分析： 因为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、功能改进，都可以在这个计划里交流。所有在笑脸计划中提出的问题、功能改进、解决方案，都将完全通过网络无偿分享给所有人。