2018-09-15 categories:
资料 tags:
mq author:
快乐成长
一直以来都想写一点关于kafka consumer的东西，特别是关于新版consumer的中文资料很少。最近Kafka社区邮件组已经在讨论是否应该正式使用新版本consumer替换老版本，笔者也觉得时机成熟了，于是写下这篇文章讨论并总结一下新版本consumer的些许设计理念，希望能把consumer这点事说清楚，从而对广大使用者有所帮助。
在开始之前，我想花一点时间先来明确一些概念和术语，这会极大地方便我们下面的讨论。另外请原谅这文章有点长，毕竟要讨论的东西很多，虽然已然删除了很多太过细节的东西。
一、 误区澄清与概念明确
1 Kafka的版本
很多人在Kafka中国社区(替群主做个宣传，QQ号：162272557)提问时的开头经常是这样的：“我使用的kafka版本是2.10/2.11, 现在碰到一个奇怪的问题。。。。” 无意冒犯，但这里的2.10/2.11不是kafka的版本，而是编译kafka的Scala版本。Kafka的server端代码是由Scala语言编写的，目前Scala主流的3个版本分别是2.10、2.11和2.12。实际上Kafka现在每个PULL request都已经自动增加了这三个版本的检查。下图是我的一个PULL request，可以看到这个fix会同时使用3个scala版本做编译检查：
目前广泛使用kafka的版本应该是这三个大版本：0.8.x， 0.9.x和0.10.* 。 这三个版本对于consumer和consumer group来说都有很大的变化，我们后面会详谈。
2 新版本 VS 老版本
“我的kafkaoffsetmonitor为什么无法监控到offset了？”——这是我在Kafka中国社区见到最多的问题，没有之一！实际上，Kafka 0.9开始提供了新版本的consumer及consumer group，位移的管理与保存机制发生了很大的变化——新版本consumer默认将不再保存位移到zookeeper中，而目前kafkaoffsetmonitor还没有应对这种变化(虽然已经有很多人在要求他们改了，详见https://github.com/quantifind/KafkaOffsetMonitor/issues/79)，所以很有可能是因为你使用了新版本的consumer才无法看到的。关于新旧版本，这里统一说明一下：kafka0.9以前的consumer是使用Scala编写的，包名结构是kafka.consumer.*，分为high-level consumer和low-level consumer两种。我们熟知的ConsumerConnector、ZookeeperConsumerConnector以及SimpleConsumer就是这个版本提供的；自0.9版本开始，Kafka提供了java版本的consumer，包名结构是o.a.k.clients.consumer.*，熟知的类包括KafkaConsumer和ConsumerRecord等。新版本的consumer可以单独部署，不再需要依赖server端的代码。
二、消费者组 (Consumer Group)
1 什么是消费者组
其实对于这些基本概念的普及，网上资料实在太多了。我本不应该再画蛇添足了，但为了本文的完整性，我还是要花一些篇幅来重谈consumer group，至少可以说说我的理解。值得一提的是，由于我们今天基本上只探讨consumer group，对于单独的消费者不做过多讨论。
什么是consumer group? 一言以蔽之，consumer group是kafka提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者或消费者实例(consumer instance)，它们共享一个公共的ID，即group ID。组内的所有消费者协调在一起来消费订阅主题(subscribed
…
阅读全文
2018-09-15 categories:
资料 tags:
mq author:
快乐成长
1 概述
Kakfa起初是由LinkedIn公司开发的一个分布式的消息系统，后成为Apache的一部分，它使用Scala编写，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark等都支持与Kafka集成。Kafka凭借着自身的优势，越来越受到互联网企业的青睐，唯品会也采用Kafka作为其内部核心消息引擎之一。Kafka作为一个商业级消息中间件，消息可靠性的重要性可想而知。如何确保消息的精确传输?如何确保消息的准确存储?如何确保消息的正确消费?这些都是需要考虑的问题。本文首先从Kafka的架构着手，先了解下Kafka的基本原理，然后通过对kakfa的存储机制、复制原理、同步原理、可靠性和持久性保证等等一步步对其可靠性进行分析，最后通过benchmark来增强对Kafka高可靠性的认知。
2 Kafka体系架构
如上图所示，一个典型的Kafka体系架构包括若干Producer(可以是服务器日志，业务数据，页面前端产生的page view等等)，若干broker(Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高)，若干Consumer (Group)，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。Producer使用push(推)模式将消息发布到broker，Consumer使用pull(拉)模式从broker订阅并消费消息。
名词解释：
2.1 Topic & Partition
一个topic可以认为一个一类消息，每个topic将被分成多个partition，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被追加到log文件的尾部，每条消息在文件中的位置称为offset(偏移量)，offset为一个long型的数字，它唯一标记一条消息。每条消息都被append到partition中，是顺序写磁盘，因此效率非常高(经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证)。
每一条消息被发送到broker中，会根据partition规则选择被存储到哪一个partition。如果partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。(如果一个topic对应一个文件，那这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition解决了这个问题)。在创建topic时可以在$KAFKA_HOME/config/server.properties中指定这个partition的数量(如下所示)，当然可以在topic创建之后去修改partition的数量。
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result … 阅读全文
2018-09-15 categories:
资料 tags:
mq author:
快乐成长
前言
Kafka 是 LinkedIn 开发的一个分布式的消息中间件。由于其高吞吐量、可水平扩展等特性，目前被广泛使用，已经是目前大数据生态系统中不可或缺的一环，有关其详细介绍可以查看官方的文档。Kafka 的流行源于他优秀的设计，如依靠磁盘（以及操作系统的 Page Cache）而不是内存来存储队列数据、充分使用零拷贝（zero-copy）以减少数据在不同内存空间间的拷贝、数据尽可能的使用顺序读写等。今天准备深度解析 kafka 的网络通信模块，来学习下实现一个高吞吐量的系统要设计一个怎么样的网络通信机制。
网络通讯协议
作为一个消息队列，涉及的网络通信主要有两块：
消息生产者与消息队列服务器之间（Kafka 中是生产者向队列「推」消息）
消息消费者与消息队列服务器之间（Kafka 中是消费者向队列「拉」消息）
要实现上述的网络通信，我们可以使用 HTTP 协议，比如服务端内嵌一个 jetty 容器，通过 servlet 来实现客户端与服务端之间的交互，但是其性能存在问题，无法满足高吞吐量这个需求。要实现高性能的网络通信，我们可以使用更底层的 TCP 或者 UDP 来实现自己的私有协议，而 UDP 协议是不可靠的传输协议，毕竟我们不希望一条消息在投递或者消费途中丢失了，所以 Kafka 选择 TCP 作为服务间通讯的协议。
网络 IO 模型
谈到网络通信，绕不过 IO 模型，IO 模型主要是同步与异步，阻塞与非阻塞之间进行选择。
…
阅读全文
2018-09-15 categories:
资料 tags:
mq author:
快乐成长
Kafka
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
1.前言
消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。
1.1 Kafka的特性:
- 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
- 可扩展性：kafka集群支持热扩展
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
- 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
- 高并发：支持数千个客户端同时读写
1.2 Kafka的使用场景：
- 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
- 消息系统：解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
- 流式处理：比如spark streaming和storm
- 事件源
1.3 Kakfa的设计思想
- Kakfa Broker
…
阅读全文
2018-09-14 categories:
资料 tags:
mq author:
快乐成长
Kafka 跨集群同步方案——Kafka内置的MirrorMaker工具
该方案解决Kafka跨集群同步、创建Kafka集群镜像等相关问题，主要使用Kafka内置的MirrorMaker工具实现。
Kafka镜像即已有Kafka集群的副本。下图展示如何使用MirrorMaker工具创建从源Kafka集群（source cluster）到目标Kafka集群（target cluster）的镜像。该工具通过Kafka consumer从源Kafka集群消费数据，然后通过一个内置的Kafka producer将数据重新推送到目标Kafka集群。
一、如何创建镜像
使用MirrorMaker创建镜像是比较简单的，搭建好目标Kafka集群后，只需要启动mirror-maker程序即可。其中，一个或多个consumer配置文件、一个producer配置文件是必须的，whitelist、blacklist是可选的。在consumer的配置中指定源Kafka集群的Zookeeper，在producer的配置中指定目标集群的Zookeeper（或者broker.list）。
kafka-run-class.sh kafka.tools.MirrorMaker –consumer.config sourceCluster1Consumer.config –consumer.config sourceCluster2Consumer.config –num.streams 2 –producer.config targetClusterProducer.config –
…
阅读全文
2018-09-12 categories:
资料 tags:
mq author:
快乐成长
作为中间件，消息队列是分布式应用间交换信息的重要组件。消息队列可驻留在内存或磁盘上, 队列可以存储消息直到它们被应用程序读走。通过消息队列，应用程序可以在不知道彼此位置的情况下独立处理消息，或者在处理消息前不需要等待接收此消息。所以消息队列可以解决应用解耦、异步消息、流量削锋等问题，是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。下面对消息队列就直接使用MQ表示。
现在比较常见的MQ产品主要是ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ，当然还有很多其他的产品。因为个人水平有限，就简单的比较下这几种MQ的优缺点，作为自己选型的参考。
1 ZeroMQ
ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP,
…
阅读全文
2018-09-12 categories:
资料 tags:
mq author:
快乐成长
王烨 · 2016-07-01 16:10
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。
何时需要消息队列
当你需要使用消息队列时，首先需要考虑它的必要性。可以使用mq的场景有很多，最常用的几种，是做业务解耦/最终一致性/广播/错峰流控等。反之，如果需要强一致性，关注业务逻辑的处理结果，则RPC显得更为合适。
解耦
解耦是消息队列要解决的最本质问题。所谓解耦，简单点讲就是一个事务，只关心核心的流程。而需要依赖其他系统但不那么重要的事情，有通知即可，无需等待结果。换句话说，基于消息的模型，关心的是“通知”，而非“处理”。
最终一致性
最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。当然有个时间限制，理论上越快越好，但实际上在各种异常的情况下，可能会有一定延迟达到最终一致状态，但最后两个系统的状态是一样的。
A扣钱成功，调用B加钱接口失败。
A扣钱成功，调用B加钱接口虽然成功，但获取最终结果时网络异常引起超时。
A扣钱成功，B加钱失败，A想回滚扣的钱，但A机器down机。
可见，想把这件看似简单的事真正做成，真的不那么容易。所有跨VM的一致性问题，从技术的角度讲通用的解决方案是：
强一致性，分布式事务，但落地太难且成本太高，后文会具体提到。
最终一致性，主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前，先把事情记录下来，然后去做不确定的事情，结果可能是：成功、失败或是不确定，“不确定”（例如超时等）可以等价为失败。成功就可以把记录的东西清理掉了，对于失败和不确定，可以依靠定时任务等方式把所有失败的事情重新搞一遍，直到成功为止。
最终一致性不是消息队列的必备特性，但确实可以依靠消息队列来做最终一致性的事情。另外，所有不保证100%不丢消息的消息队列，理论上无法实现最终一致性。好吧，应该说理论上的100%，排除系统严重故障和bug。
广播
消息队列的基本功能之一是进行广播。如果没有消息队列，每当一个新的业务方接入，我们都要联调一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。
错峰与流控
试想上下游对于事情的处理能力是不同的。比如，Web前端每秒承受上千万的请求，并不是什么神奇的事情，只需要加多一点机器，再搭建一些LVS负载均衡设备和Nginx等即可。但数据库的处理能力却十分有限，即使使用SSD加分库分表，单机的处理能力仍然在万级。由于成本的考虑，我们不能奢求数据库的机器数量追上前端。阅读全文
2018-09-01 categories:
资料 tags:
mq author:
快乐成长
主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。
##########################################################################################
美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用。”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控。所以Martin Fowler强调：分布式调用的第一原则就是不要分布式。这句话看似颇具哲理，然而就企业应用系统而言，只要整个系统在不停地演化，并有多个子系统共同存在时，这条原则就会被迫打破。盖因为在当今的企业应用系统中，很难寻找到完全不需要分布式调用的场景。Martin Fowler提出的这条原则，一方面是希望设计者能够审慎地对待分布式调用，另一方面却也是分布式系统自身存在的缺陷所致。无论是CORBA，还是EJB 2；无论是RPC平台，还是Web Service，都因为驻留在不同进程空间的分布式组件，而引入额外的复杂度，并可能对系统的效率、可靠性、可预测性等诸多方面带来负面的影响。
然而，不可否认的是在企业应用系统领域，我们总是会面对不同系统之间的通信、集成与整合，尤其当面临异构系统时，这种分布式的调用与通信变得越重要，它在架构设计中就更加凸显其价值。并且，从业务分析与架构质量的角度来讲，我们也希望在系统架构中尽可能地形成对服务的重用，通过独立运行在进程中服务的形式，彻底解除客户端与服务端的耦合。这常常是架构演化的必然道路。在我的同事陈金洲发表在InfoQ上的文章《架构腐化之谜》中，就认为可以通过“将独立的模块放入独立的进程”来解决架构因为代码规模变大而腐化的问题。
随着网络基础设施的逐步成熟，从RPC进化到Web Service，并在业界开始普遍推行SOA，再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广，分布式架构在企业应用中开始呈现出不同的风貌，然而殊途同归，这些分布式架构的目标仍然是希望回到建造巴别塔的时代，系统之间的交流不再为不同语言与平台的隔阂而产生障碍。正如Martin Fowler在《企业集成模式》一书的序中写道：“集成之所以重要是因为相互独立的应用是没有生命力的。我们需要一种技术能将在设计时并未考虑互操作的应用集成起来，打破它们之间的隔阂，获得比单个应用更多的效益”。这或许是分布式架构存在的主要意义。
1、集成模式中的消息模式
归根结底，企业应用系统就是对数据的处理，而对于一个拥有多个子系统的企业应用系统而言，它的基础支撑无疑就是对消息的处理。与对象不同，消息本质上是一种数据结构（当然，对象也可以看做是一种特殊的消息），它包含消费者与服务双方都能识别的数据，这些数据需要在不同的进程（机器）之间进行传递，并可能会被多个完全不同的客户端消费。在众多分布式技术中，消息传递相较文件传递与远程过程调用（RPC）而言，似乎更胜一筹，因为它具有更好的平台无关性，并能够很好地支持并发与异步调用。对于Web Service与RESTful而言，则可以看做是消息传递技术的一种衍生或封装。在《面向模式的软件架构（卷四）》一书中，将关于消息传递的模式划归为分布式基础设施的范畴，这是因为诸多消息中间件产品的出现，使得原来需要开发人员自己实现的功能，已经可以直接重用。这极大地降低了包括设计成本、实现成本在内的开发成本。因此，对于架构师的要求也就从原来的设计实现，转变为对业务场景和功能需求的判断，从而能够正确地进行架构决策、技术选型与模式运用。
常用的消息模式
在我参与过的所有企业应用系统中，无一例外地都采用（或在某些子系统与模块中部分采用）了基于消息的分布式架构。但是不同之处在于，让我们做出架构决策的证据却迥然而异，这也直接影响我们所要应用的消息模式。
消息通道（Message Channel）模式
我们常常运用的消息模式是Message Channel（消息通道）模式，如图1所示。
图1 Message Channel模式（图片来自eaipatterns ）
消息通道作为在客户端（消费者，Consumer）与服务（生产者，Producer）之间引入的间接层，可以有效地解除二者之间的耦合。只要实现规定双方需要通信的消息格式，以及处理消息的机制与时机，就可以做到消费者对生产者的“无知”。事实上，该模式可以支持多个生产者与消费者。例如，我们可以让多个生产者向消息通道发送消息，因为消费者对生产者的无知性，它不必考虑究竟是哪个生产者发来的消息。
虽然消息通道解除了生产者与消费者之间的耦合，使得我们可以任意地对生产者与消费者进行扩展，但它又同时引入了各自对消息通道的依赖，因为它们必须知道通道资源的位置。要解除这种对通道的依赖，可以考虑引入Lookup服务来查找该通道资源。例如，在JMS中就可以通过JNDI来获取消息通道Queue。若要做到充分的灵活性，可以将与通道相关的信息存储到配置文件中，Lookup服务首先通过读取配置文件来获得通道。
消息通道通常以队列的形式存在，这种先进先出的数据结构无疑最为适合这种处理消息的场景。微软的MSMQ、IBM MQ、JBoss MQ以及开源的RabbitMQ、Apache ActiveMQ都通过队列实现了Message Channel模式。因此，在选择运用Message Channel模式时，更多地是要从质量属性的层面对各种实现了该模式的产品进行全方位的分析与权衡。例如，消息通道对并发的支持以及在性能上的表现；消息通道是否充分地考虑了错误处理；对消息安全的支持；以及关于消息持久化、灾备（fail over）与集群等方面的支持。因为通道传递的消息往往是一些重要的业务数据，一旦通道成为故障点或安全性的突破点，对系统就会造成灾难性的影响。在本文的第二部分，我将给出一个实际案例来阐释在进行架构决策时应该考虑的架构因素，并由此做出正确地决策。
发布者-订阅者（Publisher-Subscriber）模式
一旦消息通道需要支持多个消费者时，就可能面临两种模型的选择：拉模型与推模型。拉模型是由消息的消费者发起的，主动权把握在消费者手中，它会根据自己的情况对生产者发起调用。如图2所示：
图2 拉模型 … 阅读全文
2018-08-31 categories:
资料 tags:
mq author:
快乐成长
1、消息异常处理
1、1 处理机制：死信队列和异常消息队
死信队列：由于某种原因无法传递的消息都放置在死信队列上，主要触发点（MCA 如果远程消息不能交付，MCA 发送的消息不能进行数据转换，Trigger Monitor 出发消息失败）。
回退队列：在外部应用在消费队列中消息时，如果发生异常，会发送回滚命令，回滚后的消息始终会放在队列的顶部，不断被处理和回滚，导致队陷入死循环状态，为了解决这个问题，MQ提供一种机制，选中队列右键–》属性–》存储器，设置回退队列和阀值，如设置队列为q1，阀值为2，则在rollback两次后将消息转入q1。
两者都为消息的可靠传输提供一种机制来处理异常。
两者的区别：
1. 起作用的阶段，死信队列主要在发送阶段，回退队列主要在消息的消费阶段生成。
2. 死信队列由系统触发， 回退队列主要由应用发送rollback触发。
3. 死信队列一个队列管理器只有一个，而回退队列可以为每个队列设置一个。
1.2处理手段：
首先要根据消息的类型，然后再根据是死信和回退队列进行处理。
a) 针对死信队列，需要分析具体原因，重新发起，最后做成自动恢复
b)针对回退队列，如果是能容忍部分丢弃的消息，那么将对应的回退队列的信息持久化即可；如果不能容忍丢失，那么需要人工介入处理。
从最终用户的角度来说，系统应该做到不感知到死信，针对回退的信息，人工介入进行处理，处理的过程中，是否不允许进行同样的业务，需要根据业务的需求来做。
当正常的消息到了业务队列后,消费者监听这个队列进行处理,在消费者处理的过程中,难免会有一些消息处理失败,因为业务的种种原因,但是这些消息一旦失败,那么就会影响性能和后面的消息的消费,这时候就需要一个死信队列,来存放这个消费不了的消息,进入死信队列后,在进行其他处理.
工作的项目中使用了消息队列，需要注意几个关键问题：
2、顺序消息
消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生了
…
阅读全文
2018-08-07 categories:
资料 tags:
mq author:
快乐成长
我们可以在发送消息时，指定消息的权重，broker可以建议
JMS标准中约定priority可以为0~9的数值，值越大表示权重越高，默认值为4。不过activeMQ中各个存储器对priority的支持并非完全一样。比如JDBC存储器可以支持0~9，因为JDBC存储器可以基于priority对消息进行排序和索引化；但是对于kahadb/levelDB等这种基于日志文件的存储器而言，priority支持相对较弱，只能识别三种优先级(LOW: < 4,NORMAL: =4,HIGH: > 4)。在broker端，默认是不支持priority排序的，我们需要手动开启:
<policyEntry queue=“>” prioritizedMessages=“true” />
一旦开启了此属性，此后消息存储时，将会按照prioprity的倒序索引化消息(比如kahadb B+Tree，此后priority将作为索引的一部分)。此后broker从存储器中获取消息时，权重较高的消息将会被优先获取；对于JDBC等其他存储器，可能在获取消息时，按照priority作为排序列来筛选消息。
我们首先简单的描述一下，消息在broker端pending的过程，这涉及到prefetch机制以及消息是否持久化等方面的问题。在broker端，为了优化Consumer消费的效率，通常开启prefetch策略，即从通道中(Queue/Topic)批量加载多条消息，这些消息可能来自内存(非持久化)，也可能来自存储文件(持久化消息，或者非持久化消息被swap到临时文件中)；borker会为每个Consumer创建一个基于内存的pending buffer，用来保存即将发送给Consumer的消息列表。当buffer中的消息被Consumer消费之后，将会从内存或者文件中继续加载多条消息，然后再根据需要将一定量的消息放入到pending buffer中。由此可见，我们只能保证每次prefetch的消息列表是按照priority排序的，但是有可能在buffer中的消息还没有发送之前，会有更高优先级的消息被写入文件或内存，事实上这已经不能改变消息发送的顺序了；因为我们无法在全局范围内，保证Consumer即将消费的消息是权重最高的！！
不过对于“非持久化”类型的消息(如果没有被swap到临时文件)，它们被保存在内存中，它们不存在从文件Paged in到内存的过程，因为可以保证优先级较高的消息，总是在prefetch的时候被优先获取，这也是“非持久化”消息可以担保消息发送顺序的优点。
Broker在收到Producer的消息之后，将会把消息cache到内存，如果消息需要持久化，那么同时也会把消息写入文件；如果通道中Consumer的消费速度足够快(即积压的消息很少，尚未超过内存限制，我们通过上文能够知道，每个通道都可以有一定的内存用来cache消息)，那么消息几乎不需要从存储文件中Paged In，直接就能从内存的cache中获取即可，这种情况下，priority可以担保“全局顺序”；不过，如果消费者滞后太多，cache已满，就会触发新接收的消息直接保存在磁盘中，那么此时，priority就没有那么有效了。
在Queue中，prefetch的消息列表默认将会采用“轮询”的方式(roundRobin，注意并不是roundRobinDispatch )[备注：因为Queue不支持任何DispatchPolicy]，依次添加到每个consumer的pending buffer中，比如有m1-m2-m3-m4四条消息，有C1-C2两个消费者，那么: m1->C1,m2->C2,m3->C1,m4->C2。这种轮序方式，会对基于权重的消息发送有些额外的影响，假如四条消息的权重都不同，但是(m1,m3)->C1，事实上m2的权重>m3,对于C1而言，它似乎丢失了“顺序性”。
Iterator it = pendingList.iterator();
…
阅读全文
