由于meta不像activeMQ等产品，它们的broker端承载了非常多的功能，而像meta这样追求性能为目的的消息中间件，则是把broker端的功能弱化，同时加强了client端的某些功能，如当前client的消息offset的存储、从broker中pull消息等。

下面我们从消息pull这样一个client端最重要的功能作为分析的主线来了解meta中client的实现。

下面是client端执行pull消息的处理流程示意图:

1.通过ZKLoadRebalanceListener的rebalance方法，根据该client所订阅topic的分区数量来初始化对应数量的FetchRequest实例，并把它们放到FetchRequestQueue中(先进先出)。

2.消息抓取管理器初始化fetchRunners线程池，并启动所有线程对FetchRequestQueue进行读请求的操作。

3.当FetchRequestQueue中有请求时，则执行FetchRequestRunner线程中的processRequest方法，进行后续的操作。

4.通过SimpleMessageConsumer(消息消费者基类)的fetch方法从broker端获取某topic的某分区的消息数据byte组。

5.对broker端返回的消息数据byte组进行操作，解析出一条条消息，并对这些消息进行消费，具体代码实现在FetchRequestRunner类的notifyListener方法，它是消息消费的核心方法，后面我们会重点介绍。

6.FetchRequestRunner处理完一次从broker获取消息并消费的过程后，会把FetchRequest实例重新放回FetchRequestQueue中，重复进行下一轮操作。

上面是client端pull消息的主过程，由于meta的client涉及的功能也较多，为了更进一步了解client端的实现细节，我们从下面几个方面做更进一步的分析

pull模型的轮训时间

很多用户在一看到消息的获取是通过client端主动pull的方式，就感觉和activeMQ等其他消息中间件所采用的broker主动推送消息到client的方式相比较，实时性有所降低。但通过对meta源码的分析，发现它的实时性还是可以保证的，具体实现方法分析如下：

轮训时间的控制在FetchRequestQueue类的take方法中的如下几行代码：

final long delay = first.getDelay(TimeUnit.NANOSECONDS); if (delay > 0) {       final long tl = this.available.awaitNanos(delay); } 

delay值的设置是按照下面规则进行的：

• 初始化为0，所以第一次该请求会立即和broker端通讯，以获得消息组。
• 大部分情况下pull的轮训间隔为0，所以它的实时性还是可以保证的。

Meta使用zookeeper的细节

meta对zookeeper非常依赖，而且重要的信息同步都是通过它完成的，官方文档对这一块的说明也不多，所以，我们对meta的分析就从这开始，当我们清晰meta中zookeeper的使用细节后，meta的内部实现原理也就基本清晰了。

meta里使用zookeeper最典型的就是类ZKLoadRebalanceListener的 rebalance()方法，该方法使用到了很多zookeeper的znode，下面我们对这个方面做一个详细介绍：

rebalance方法是用来计算某消息消费者具体应该消费哪个meta服务器节点上的哪些分区中的消息(也就是“消费者的负载平衡”)。该方面在下面两种情况下被触发：

• 监视同一个消费者分组的consumer列表是否有变化；
• 监视订阅的topic下的broker节点是否有新增或删除；

当上面两种情况发生时，zookeeper的机制会自动触发到rebalance方法，它的具体算法如下：

1.从zookeeper的'/meta/consumers/某消费者组/ids/某消费者id'节点上获取该消费者的所有订阅了的主题;

2.从zookeeper的'/meta/brokers/ids'节点上获取所有的broker列表;

3.从zookeeper的'/meta/consumers/某消费者组/ids/'、'/meta/consumers/某消费者组/ids/某消费者id'这两个节点中获得每个topic下有哪些消费者;

4.从zookeeper的'/meta/brokers/topics/某topic'节点获得对应topic在broker(包括:master和slaves)里有哪些partition;

5.从上面获得的所有这些信息，调用类ZKLoadRebalanceListener中getRelevantTopicMap方法，判断最新的partition列表或consumer列表和当前在用的是否有变化，如果没有变化则再补充做一个动作(因为虽然partition和consumer都没有新增或删除，但可能cluster的结构发生变化了)：对集群做一个比较，看是否有机器down或新增；如果没有变化则继续进行后续rebalance操作；

6.如果经过上面的操作确认相关partition列表或consumer列表有变化，则根据'负载均衡策略'获取某个consumer对应的partition列表，然后根据之前老的和最新的partition列表做相关操作，如新分区在zookeeper上的挂载、释放等操作；

上面是client端一个比较重要的功能，也是zookeeper在meta里一个用的较多的地方。

Meta的HA

HA是任何进入生产环境的软件都需要考虑的一个重要因素，meta提供两种HA的方式：同步和异步(推荐使用异步方式)。

官方提供的文档里已经很清晰说明了HA的场景，这里我们再补充一些官方文档中未详细说明的部分：

• meta采用冷备方式来实现HA，任何主、备的切换都得重启相关broker。
• 任何时候只有master可以执行写操作；实现代码在BrokerConnectionListener类的syncedUpdateBrokersInfo方法,该方法从zookeeper上同步最新的master列表供producer使用。
• client可以连接cluster上的任何一台机器包括master和slave,作为它的消息来源，类似数据库的读写分离。
• 如果master因为某种原因当机，则必须手动停止某台slave并对它进行相关配置操作，并启动它使它成为新的master。当那台坏了的master修复后，它将作为一台新的slave加入集群。
• 在master上不停机的情况下新增一个topic，这个新增的topic不能自动的同步到slave上，必须通过某种方式把master上的server.ini同步到所有slave上，然后通过人工重启或通过jmx重启slave。

同步HA的切换过程：

生产环境中有一台master和一个同步slave,slave是不注册到zookeeper上的，当master当机，则所有连接到该broker的生产者和消费者都停止正常工作。然后人工停止slave,并新增samsa_master.properties配置文件，修改其中recoverOffset属性为true。并且修改server.ini中的brokerId为故障master的id，这些修改做完后，重启slave。这样它就成为新的master对外提供服务了。

Meta的transaction实现

对事务的支持是meta的一个重要特点，目前它支持XA和本地事务，下面我们详细对XA事务进行分析，由于本地事务相对简单，可以参考XA的实现。

分布式事务（XA）

分布式事务介绍

分布式事务在分布式应用中是非常重要的，目前分布式事务的实现标准是XA，而在java体系中就是JTA标准。下面是XA的一个示意图：

这里我们重点说一下两阶段提交协议(2PC),它是XA的核心思想，具体示意图如下：

具体更多关于XA的细节请参考XA的接口规范。

meta的实现

meta里事务的实现主要是如下几个类：

• TransactionalCommandProcessor：事务命令处理器。它主要作用是接收client端发过来的各种请求，如beginTransaction、prepare、commit、rollback、新增消息等。
• JournalTransactionStore：基于文件方式的事务存储引擎。
• JournalStore：具体存储事务的文件存储类。

它们3者之间的关系是：TransactionalCommandProcessor接收client端的各种事务请求，然后调用JournalTransactionStore进行事务存储，JournalTransactionStore根据不同的client请求调用JournalStore具体保存事务信息到磁盘文件。

下面通过一个示意图来进一步进行说明：

client通过调用beginTransaction来新开始一个事务(在meta里就是一个Tx实例),并把它放在JournalTransactionStore类的inflightTransactions队列里，然后client就可以在这个Tx中新增消息，但这些新增的消息是放在JournalStore文件里，并且完整的保存在内存中(由于meta目前没有专门的内存管理机制，当事务数量特别大的时候，这个地方有可能会出现内存溢出)。当client进行2PC中的prepare时，事务从inflightTransactions队列移到preparedTransactions队列，并保存相关信息到JournalStore。当执行commit时，该Tx的所有消息才真正放到MessageStore里供消息消费者读取。当client端发起rollback请求后，Tx被从preparedTransactions队列中删除，并保存相关信息到JournalStore。

下面我们对meta事务实现的几个重要方面做一个详细介绍：

beginTransaction

当client端的TransactionContext(XAResource的实现)调用start方法，broker接收到请求后，启动一个新事务。

新增消息

处理序列图如下：

当事务begin后，client端向broker发送多条消息存储的请求，broker收到请求后会调用JournalTransactionStore的addMessage方法。该方法把请求存储在事务日志文件中(JournalStore)，同时新建或找到对应的Tx实例，把这些消息存储请求保存在内存中。这里注意一点，在事务没有提交之前，这些消息存储是不会被放到对应topic消息存储文件中去的。

prepare的处理过程

处理序列图如下：

prepare的处理过程相对简单些，它只是把Tx实例从JournalTransactionStore类的inflightTransactions中移除到preparedTransactions中，同时在事务日志文件存储相关信息。

commit的处理过程

处理序列图如下：

commit过程相当复杂点。broker收到client端的commit请求，调用JournalTransactionStore的commit方法，从preparedTransactions里找到对应的Tx,把该Tx里的所有请求命令(PutCommand)，按照topic和分区分别保存到真正的topic消息存储文件中去，当全部保存完时，就会通过回调类AppendCallback的appendComplete方法记录commit日志到事务日志文件。

recover的处理过程

处理序列图如下：

recover操作发生在系统重启的时候，主要是为了还原系统上一次停止时候的事务场景，如还原处在prepare阶段的事务，rollback所有本地事务和没有prepare的XA事务。recover的处理细节包括两部分：

• 在JournalTransactionStore的构造函数中进行JournalStore的recover操作

• JournalStore的recover主要是完成从事务日志文件中按照最近的checkpoint从日志中读取所有的日志记录，并按照记录的类型APPEND_MSG和TX_OP分别进行还原操作：

  APPEND_MSG类型

  这种类型的日志记录就调用JournalTransactionStore的addMessage方法，但是不会往日志文件中重复记录该消息了。

  TX_OP类型

  这种类型的处理相当复杂点。它根据日志记录的类型又细分为下面几种

• XA_PREPARE:根据TransactionId把对应的Tx实例从JournalTransactionStore类的inflightTransactions中移到preparedTransactions中。

• XA_COMMIT和LOCAL_COMMIT:根据TransactionId从JournalTransactionStore类的inflightTransactions或preparedTransactions中找到对应的Tx实例。把该Tx内的所有消息请求对比相应topic消息存储文件中消息，如果topic消息存储文件中不存在这些消息则新增，如果存在则通过crc32校验码进行比对。

• LOCAL_ROLLBACK和XA_ROLLBACK:根据TransactionId把对应的Tx实例从JournalTransactionStore类的inflightTransactions或preparedTransactions中删除。

在TransactionalCommandProcessor的init方法中调用JournalTransactionStore类的recover操作

经过上面的recover操作后，它已经把meta重启前的事务现场在JournalTransactionStore和JournalStore中进行了还原。接下来就是TransactionalCommandProcessor类的事务现场还原，这个过程是把JournalTransactionStore类的preparedTransactions中的所有Tx在TransactionalCommandProcessor中进行还原，该过程相对简单，可参考源码实现。

经过上面这些recover步骤后，meta作为XAResource就可以继续加入XA事务了。

同步复制和异步复制

meta提供类似mysql主从复制的异步复制和同步功能，分别对应不同的可靠级别。理论上说同步复制能带来更高的可靠级别，异步复制因为延迟的存在，可能会丢失极少量的消息数据，相应地，同步复制会带来性能的损失，因为要同步写入两台甚至更多的broker机器上才算写入成功。

在实际实践中，**我更推荐采用异步复制的架构**，因为异步复制的架构相对简单，并且易于维护和恢复，对性能也没有影响。而同步复制对运维要求相对很高，机制复杂容易出错，故障恢复也比较麻烦。**异步复制加上磁盘做磁盘阵列**，足以应对非常苛刻的数据可靠性要求。

异步复制配置

假设你已经根据如何开始这份文档配置了一台broker服务器，并且配置了一个topic为test，现在你希望test能复制到另一台slave broker上来保证消息数据的高可用。你可以这样做：

1.首先，你需要部署一个新的broker，具体仍然参照如何开始这份文档，配置server.ini从master broker拷贝一份。

2.其次，配置slave文件。编辑conf/async_slave.properties：

3.执行下列命令启动slave:

4.第一次复制因为需要跟master完全同步需要耗费一定时间，你可以在数据文件的目录观察复制情况。

5.**请注意，异步复制的slave将参与消费者的消费活动，消息消费者可以从slave中获取消息并消费，消费者会随机从master和slaves中挑选一台作为消费broker。**

6.**请注意，从1.4.2开始，可以通过autoSyncMasterConfig选项配置是否自动同步master的server.ini到异步复制的slave上，当master的server.ini文件变更并通过bin/metaServer.sh reload之后，slave将监控到这一变更并自动同步。**

异步复制的局限

• 异步复制有延迟，虽然可以通过设定slaveMaxDelayInMills来控制延迟。

异步复制的故障处理

• Master永久故障： 将slave作为master启动，去除启动参数中的slave即可，也就是metaServer.sh restart
• Slave永久故障： 启动新的broker并配置作为master新的slave启动。

同步复制配置

Producer可以是一个集群，多台机器上的producer可以往同一个topic发送消息。

Meta的服务器broker一般也是一个集群，多台broker组成一个集群提供一些topic服务，生产者按照一定的路由规则往集群里某台broker发送消息，消费者按照一定的路由规则拉取某台broker上的消息。

Consumer也可以组织成一个集群来消费同一个topic，发往这个topic的消息按照一定的路由规则发送到consumer集群里的某一台机器。Consumer集群每个consumer必须拥有相同的分组名称。

Broker集群配置

Broker集群配置非常容易，假设你已经按照如何开始和服务器配置管理配置好并启用了你第一台broker,某一天你发现这个单台broker无法支撑更大的消息量，那么你可能就需要引入更多的broker作为集群来提供服务，你要做的事情很简单：

• 拷贝broker1的配置文件conf/server.ini到新的broker,假设为broker2。
• 修改broker2的server.ini,只要修改brokerId为另一个不同于broker1的值即可
• 启动broker2，这样一来broker2将和broker1组成一个服务器集群
• 在这个过程中你不需要重启任何现有的服务，包括生产者、消费者和broker1，他们都将自动感知到新的broker2

可见，配置一个集群唯一要做的就是使用同一份配置文件并定义不同的brokerId即可。

负载均衡

负载均衡和failover分不开，我们将分别讨论下生产者和消费者的负载均衡策略。我们先假定broker是一个集群，这样每个topic必定有多个分区。

生产者的负载均衡和failover

每个broker都可以配置一个topic可以有多少个分区，但是在生产者看来，一个topic在所有broker上的的所有分区组成一个分区列表来使用。

在创建producer的时候，客户端会从zookeeper上获取publish的topic对应的broker和分区列表，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，默认的策略是一个轮询的路由规则，一张图来表示

生产者在通过zk获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。考虑到我们的broker服务器软硬件配置基本一致，默认的轮询策略已然足够。

如果你想实现自己的负载均衡策略，可以实现上文提到过的PartitionSelector接口，并在创建producer的时候传入即可。

在broker因为重启或者故障等因素无法服务的时候，producer通过zookeeper会感知到这个变化，将失效的分区从列表中移除做到fail over。因为从故障到感知变化有一个延迟，可能在那一瞬间会有部分的消息发送失败。

消费者的负载均衡

消费者的负载均衡会相对复杂一些。我们这里讨论的是单个分组内的消费者集群的负载均衡，不同分组的负载均衡互不干扰，没有讨论的必要。 消费者的负载均衡跟topic的分区数目紧密相关，要考察几个场景。 首先是，单个分组内的消费者数目如果比总的分区数目多的话，则多出来的消费者不参与消费，如图

其次，如果分组内的消费者数目比分区数目小，则有部分消费者要额外承担消息的消费任务，具体见示例图如下

综上所述，单个分组内的消费者集群的负载均衡策略如下

• 每个分区针对同一个group只挂载一个消费者
• 如果同一个group的消费者数目大于分区数目，则多出来的消费者将不参与消费
• 如果同一个group的消费者数目小于分区数目，则有部分消费者需要额外承担消费任务

Meta的客户端会自动帮处理消费者的负载均衡，它会将消费者列表和分区列表分别排序，然后按照上述规则做合理的挂载。

从上述内容来看，合理地设置分区数目至关重要。如果分区数目太小，则有部分消费者可能闲置，如果分区数目太大，则对服务器的性能有影响。

在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过 zookeeper watch消费者列表），然后重新进行负载均衡，保证所有的分区都有消费者进行消费。

服务端配置

Meta服务端配置主要在服务器conf目录下的server.ini文件，整体配置分为三部分：系统参数、zookeeper参数以及topic配置。系统参数在system section，zookeeper参数配置在zookeeper section，而topic的配置是在topic=xxxx section。具体说明如下：

系统参数部分

系统参数配置都放在[system]下面：

• brokerId: 服务器集群中唯一的id，必须为整型0-1024之间。对服务器集群的定义是使用同一个zookeeper并且在zookeeper上的root path相同，具体参见zookeeper配置。

• hostName: 服务器hostname，默认取本机IP地址，如果你是多网卡机器，可能需要明确指定。服务器会将此hostname加上端口写入到zookeeper提供给客户端发现。

• serverPort:服务器端口，默认8123。PS. 选择8123是因为这蕴含着作者儿子的生日。

• numPartitions:系统默认情况下每个topic的分区数目，默认为1，可被topic配置覆盖。单个服务器的总分区数目不建议超过1000，太多将导致频繁的磁盘寻道严重影响IO性能。

• dataPath: 服务器数据文件路径，默认在~home/meta下,每个topic可以覆盖此配置，对于多块磁盘的机器，可设置不同topic到不同磁盘来提升IO效率。

• dataLogPath：数据日志文件路径，主要存放事务日志，默认跟dataPath一致，最好单独设置到不同的磁盘或者目录上。如果为空，使用指定的dataPath

• getProcessThreadCount: 处理get请求的并发线程数，默认为CPUS*10。

• putProcessThreadCount: 处理put请求的并发线程数，默认为CPUS*10。

• maxSegmentSize: 单个数据文件的大小，默认为1G。默认无需修改此选项。

• maxTransferSize: 传输给消费者的最大数据大小，默认为1M，请根据你的最大消息大小酌情设置，如果太小，每次无法传输一个完整的消息给消费者，导致消费者消费停滞。可设置成一个大数来取消限制。

1.4.3引入的新参数：

• acceptPublish: 是否接收消息，默认为true；如果为false，则不会注册发送信息到zookeeper上，客户端当然无法发送消息到该broker。本参数可以被后续的topic配置覆盖。

• acceptSubscribe: 与acceptPublish类似，默认也为true；如果为false，则不会注册消费信息到zookeeper上，消费者无法发现该broker，当然无法从该broker消费消息。本参数可以被后续的topic配置覆盖。

数据可靠性参数

Meta保证消息可靠性是建立在磁盘可靠性的基础上，发送的每一条消息都保证是在“写入磁盘”的情况下才返回给客户端应答。这里有两个关键参数可以控制：

• unflushThreshold: 每隔多少条消息做一次磁盘sync，强制将更改的数据刷入磁盘。默认为1000。也就是说在掉电情况下，最多允许丢失1000条消息。可设置为0，强制每次写入都sync。在设置为0的情况下，服务器会自动启用group commit技术，将多个消息合并成一次sync来提升IO性能。经过测试，group commit情况下消息发送者的TPS没有受到太大影响，但是服务端的负载会上升很多。
• unflushInterval: 间隔多少毫秒定期做一次磁盘sync,默认是10秒。也就是说在服务器掉电情况下，最多丢失10秒内发送过来的消息。不可设置为小于或者等于0。

请注意，上述两个参数都可以被topic单独配置说覆盖，也就是说每个topic可以配置不同的数据可靠级别。

数据删除策略配置

默认情况下，meta是会保存不断添加的消息，然后定期对“过期”的数据进行删除或者归档处理，这都是通过下列参数控制的：

• deletePolicy: 数据删除策略，默认超过7天即删除,这里的168是小时，10s表示10秒，10m表示10分钟，10h表示10小时，不明确指定单位默认为小时。delete是指删除，超过指定时间的数据文件将被彻底从磁盘删除。也可以选择archive策略，即不对过期的数据文件做删除而是归档，当使用archive策略的时候可以选择是否压缩数据文件，如167,archive,true即选择将更改时间超过7天的数据文件归档并压缩为zip文件，如果不选择压缩，则重命名为扩展名为arc的文件。

上述两个参数都可以被topic单独配置所覆盖，也就是每个topic可以指定自己独特的删除策略。通常来说，对于不重要的topic可以将更早地将他们删除来节省磁盘空间。

事务相关配置

• maxCheckpoints: 最大保存事务checkpoint数目，默认为3，服务器在启动的时候会从最近一次checkpoint回访事务日志文件，恢复重启前的事务状态。不建议修改此参数。
• checkpointInterval：事务checkpoint时间间隔，单位毫秒，默认1小时。间隔时间太长，会导致启动的时候replay事务日志占用了太多时间，太短则可能影响到性能。
• maxTxTimeoutTimerCapacity：最大事务超时timer的数量。服务端会为每个事务启动一个定时器监控事务是否超时，定时器的数目上限通过本参数限制。限制了本参数，也变相地控制了最大可运行的事务数。默认为30000个。
• maxTxTimeoutInSeconds：最大事务超时时间，单位为秒，默认为60秒。客户端设置的事务超时时间不能超过此设定，超过将被强制限制为此设定。
• flushTxLogAtCommit：服务端对事务日志的sync策略，0表示让操作系统决定，1表示每次commit都刷盘，2表示每隔1秒刷盘一次。此参数严重影响事务性能，可根据你需要的性能和可靠性之间权衡做出一个合理的选择。通常建议设置为2，表示每隔1秒刷盘一次，也就是最多丢失一秒内的运行时事务。这样的可靠级别对大多数服务是足够的。最安全的当然是设置为1，但是将严重影响事务性能。而0的安全级别最低。安全级别上1>=2>0，而性能则是0 >= 2 > 1。

zookeeper配置

meta服务端会将自身id,topic信息和socket地址发送到zookeeper上，让客户端可以发现并连接服务器。Zookeeper相关的配置放在[zookeeper]模块下面:

• zk.zkEnable: 是否启用zookeeper，也就是是否将信息注册到zookeeper上。默认为true。对于同步复制的slave来说，本参数会被强制设置为false。
• zk.zkConnect: zookeeper服务器列表，例如localhost:1281这样的字符串。默认也是localhost:2181。请设置你的zk集群地址列表。
• zk.zkSessionTimeoutMs: zookeeper的session timeout，默认为30秒。单位毫秒。
• zk.zkConnectionTimeoutMs： zookeeper的连接超时时间，默认同样为30秒，单位毫秒。
• zk.zkSyncTimeMs: 预期的zk集群间数据同步延迟，默认为5秒，这个参数对服务器无意义。

Topic配置

服务器将提供哪些topic服务都是通过topic配置来实现的，topic配置都是在[topic=xxx]的模块下面，其中xxx就是topic名称，一个示范配置如下：

这里配置了一个名为meta-test的topic，并针对该topic启用实时统计，并将topic的在本服务器的分区数目设置为1。可见，topic配置可覆盖服务器的部分配置，包括：

• stat:是否启用实时统计，启用则会在服务端对该topic的请求做实时统计，可以通过stats topic-name协议观察到该topic运行状况，可选。
• numPartitions: 该topic在本服务器的分区总数，覆盖系统配置，可选。
• unflushInterval：每隔多少条消息做一次磁盘sync，覆盖系统配置，可选。
• unflushThreshold：每隔多少秒做一次磁盘sync，覆盖系统配置，可选。
• deletePolicy：topic的删除策略，覆盖系统配置，可选。
• deleteWhen：删除策略的执行时间，覆盖系统配置，可选。
• dataPath：设置数据文件路径，覆盖系统配置，可选。

1.4.3新增参数：

• acceptPublish: 是否接收该topic的消息，覆盖系统配置，可选。
• acceptSubscribe: 是否接受消费者的订阅，覆盖系统配置，可选。

新增Topic热部署

在新增或者删除topic并保存server.ini之后，可以通过下列命令热加载新的配置文件并生效： bin/metaServer.sh reload

使用maven，引用metaq的java client非常简单：

 也可以引用 client-extend

直接用git 将metamorphosis-example clone  下载页面：https://github.com/killme2008/metamorphosis-example 。

请注意，1.4.3及以上版本的java客户端只能连接1.4.3及以上版本的MetaQ服务器，而1.4.3之前的老客户端则没有限制。主要是因为1.4.3引入了发布和订阅topic的分离，1.4.3的新客户端只能查找到新版本的broker

消息会话工厂类

在使用消息生产者和消费者之前，需要用到消息会话工厂类——MessageSessionFactory，由这个工厂帮你创建生产者或者消费者。除了这些，MessageSessionFactory还默默无闻地在后面帮你做很多事情，包括：

1.服务的查找和发现，通过diamond和zookeeper帮你查找日常的meta服务器地址列表，diamond可以忽略。

2.连接的创建和销毁，自动创建和销毁到meta服务器的连接，并做连接复用，也就是到同一台meta的服务器在一个工厂内只维持一个连接。

3.消费者的消息存储和恢复。

4.协调和管理各种资源，包括创建的生产者和消费者的。

因此，我们首先需要创建一个会话工厂类，MessageSessionFactory仅是一个接口，它的实现类常用的是MetaMessageSessionFactory：

消息生产者  

• id: Long型的消息id,消息的唯一id，系统自动产生，用户无法设置，在发送成功后由服务器返回，发送失败则为0。
• topic: 消息的主题，订阅者订阅该主题即可接收发送到该主题下的消息，生产者通过指定发布的topic查找到需要连接的服务器地址，必须。
• data: 消息的有效载荷，二进制数据，也就是消息内容，meta永远不会修改消息内容。消息内容通常限制在1M以内，作者的建议是最好不要发送超过上百K的消息，必须。数据是否压缩也完全取决于使用方。
• attribute: 消息属性，一个字符串，可选。生产者可通过设置消息属性来让消费者简单过滤。

在sendMessage之前必须调用 MessageProducer的publish(topic)方法

这一步在发送消息前是必要的，必须先发布将要发送消息的topic（另外，metaq的broker必须要先通过配置文件设置好topic，启动broker后，客户端才可能发布消息成功，不然就会报出异常），这是为了让会话工厂帮你去查找接收这些topic的meta服务器地址并初始化连接。这个步骤针对每个topic只需要做一次，多次调用无影响。

总结下这个例子，从标准输入读入你输入的数据，并将数据封装成一个Message对象，发送到[localhost:8123]服务的 topic为metatestbroker 上。

请注意，MessageProducer是线程安全的，完全可重复使用，因此最好在应用中作为单例来使用，一次创建，到处使用，配置为spring里的singleton bean。MessageProducer创建的代价昂贵，每次都需要通过zk查找服务器并创建tcp长连接。

消息消费者

发送消息后，消费者可以接收消息了，下面的代码创建异步消费者并订阅test这个主题，等待消息送达并打印消息内容

订阅消息通过subscribe方法，这个方法接受三个参数

• topic，订阅的主题
• maxSize，因为meta是一个消费者主动拉取的模型，这个参数规定每次拉取的最大数据量，单位为字节，这里设置为1M，默认最大为1M。
• MessageListener，消息监听器，负责消息消息。

MessageListener的接口方法如下:

这里简单地打印收到的消息内容就完成消费。如果在消费过程中抛出任何异常，该条消息将会在一定间隔后重新尝试提交给MessageListener消费。在多次消费失败的情况下，该消息将会存储到消费者应用的本次磁盘，并在后台自动恢复重试消费。

在调用subscribe之后，我们还调用了completeSubscribe方法来完成订阅过程。请注意，subscribe仅是将订阅信息保存在本地，并没有实际跟meta服务器交互，要使得订阅关系生效必须调用一次completeSubscribe，completeSubscribe仅能被调用一次，多次调用将抛出异常。 为什么需要completeSubscribe方法呢，原因有二：

• 首先，subscribe方法可以被调用多次，也就是一个消费者可以消费多种topic
• 其次，如果每次调用subscribe都跟zk和meta服务器交互一次，代价太高

因此completeSubscribe一次性将所有订阅的topic生效，并处理跟zk和meta服务器交互的所有过程。

同样,MessageConsumer也是线程安全的，创建的代价不低，因此也应该尽量复用。

•     尽量复用MessageProducer,最好也是使用单例。可以单个MessageProducer发送多个topic，或者多个MessageProducer每个发送一种topic，尽量减少重复创建producer。
•     消息data的序列化方式锦衣不要使用特定语言的序列化方式（如java序列化），可以考虑 自定义协议、json、protocolbuffer、hessian等序列化协议，以便跨语言消费。
•     实现发送顺序所需要的PartitionSelector，推荐使用业务id。如：交易订单id来取模，分区列表选择固定分区发送。    
•     单条消息大小最好限制在100k以下。
•     如无顺序等特殊需求，不要实现自己的PartitionSelector，默认的轮询策略足够。

•     尽量复用MessageConsumer，最好也是使用单例。可以单个MessageConsumer订阅多种topic，或者多个MessageConsumer每个订阅一种topic，尽量减少重复创建consumer。
•     单次拉取的数据不宜过大。如果对消息实时性要求较高的应用，应将单次拉取的数据缩小，但至少要大于单条消息的大小。如果对吞吐量要求较高，可以将该值设置大一些。
•     假设消费过程非常轻量级（如：只是打印log），可以不设置MessageListener线程池，减少资源耗费。
•     假设消息发送量巨大，消费能力不高，可适当提高拉取消息线程数 fetchRunnerCount和MessageListener的线程池大小。
•     尽量在消息的消费过程中，扑捉所有异常，减少消息在本地的堆积和恢复，前提是不要遗漏消息。如确实无法处理，请主动抛出异常，以便重试。

基本概念

 消息生产者

也称为Message Producer，一般简称为producer，负责产生消息并发送消息到meta服务器。

 消息消费者

也称为Message Consumer，一般简称为consumer，负责消息的消费，meta采用pull模型，由消费者主动从meta服务器拉取数据并解析成消息并消费。

 Topic

消息的主题，由用户定义并在服务端配置。producer发送消息到某个topic下，consumer从某个topic下消费消息。

 分区(partition)

同一个topic下面还分为多个分区，如meta-test这个topic我们可以分为10个分区，分别有两台服务器提供，那么可能每台服务器提供5个分区，假设服务器分别为0和1，则所有分区为0-0、0-1、0-2、0-3、0-4、1-0、1-1、1-2、1-3、1-4。分区跟消费者的负载均衡机制相关。

 Message

消息，负载用户数据并在生产者、服务端和消费者之间传输。

 Broker

就是meta的服务端或者说服务器，在消息中间件中也通常称为broker。

 消费者分组(Group)

消费者可以是多个消费者共同消费一个topic下的消息，每个消费者消费部分消息。这些消费者就组成一个分组，拥有同一个分组名称,通常也称为消费者集群

 Offset

可靠性

Metamorphosis的可靠性保证贯穿客户端和服务器。

生产者的可靠性保证

消息生产者发送消息后返回SendResult，如果isSuccess返回为true,则表示消息已经确认发送到服务器并被服务器接收存储。整个发送过程是一个同步的过程。保证消息送达服务器并返回结果。

服务器的可靠性保证

消息生产者发送的消息，meta服务器收到后在做必要的校验和检查之后的第一件事就是写入磁盘，写入成功之后返回应答给生产者。因此，可以确认每条发送结果为成功的消息服务器都是写入磁盘的。

写入磁盘，不意味着数据落到磁盘设备上，毕竟我们还隔着一层os，os对写有缓冲。Meta有两个特性来保证数据落到磁盘上

• 每1000条（可配置），即强制调用一次force来写入磁盘设备。
• 每隔10秒（可配置），强制调用一次force来写入磁盘设备。

因此,Meta通过配置可保证在异常情况下（如磁盘掉电）10秒内最多丢失1000条消息。当然通过参数调整你甚至可以在掉电情况下不丢失任何消息。

服务器通常组织为一个集群，一条从生产者过来的消息可能按照路由规则存储到集群中的某台机器。Meta已经实现高可用的HA方案，类似mysql的同步和异步复制，将一台meta服务器的数据完整复制到另一台slave服务器，并且slave服务器还提供消费功能（同步复制不提供消费）。

消费者的可靠性保证

消息的消费者是一条接着一条地消费消息，只有在成功消费一条消息后才会接着消费下一条。如果在消费某条消息失败（如异常），则会尝试重试消费这条消息（默认最大5次），超过最大次数后仍然无法消费，则将消息存储在消费者的本地磁盘，由后台线程继续做重试。而主线程继续往后走，消费后续的消息。因此，只有在MessageListener确认成功消费一条消息后，meta的消费者才会继续消费另一条消息。由此来保证消息的可靠消费。

消费者的另一个可靠性的关键点是offset的存储，也就是拉取数据的偏移量。我们目前提供了以下几种存储方案

• zookeeper，默认存储在zoopkeeper上，zookeeper通过集群来保证数据的安全性。
• mysql，可以连接到您使用的mysql数据库，只要建立一张特定的表来存储。完全由数据库来保证数据的可靠性。
• file，文件存储，将offset信息存储在消费者的本地文件中，适合消费者分组只有一个消费者的情况，无需共享offset信息。

Offset会定期保存，并且在每次重新负载均衡前都会强制保存一次。

顺序

很多人关心的消息顺序，希望消费者消费消息的顺序跟消息的发送顺序是一致的。比如，我发送消息的顺序是A、B、C，那么消费者消费的顺序也应该是A、B、C。乱序对某些应用可能是无法接受的。

Metamorphosis对消息顺序性的保证是有限制的，默认情况下，消息的顺序以谁先达到服务器并写入磁盘，则谁就在先的原则处理。并且，发往同一个分区的消息保证按照写入磁盘的顺序让消费者消费，这是因为消费者针对每个分区都是按照从前到后递增offset的顺序拉取消息。

Meta可以保证，在单线程内使用该producer发送的消息按照发送的顺序达到服务器并存储，并按照相同顺序被消费者消费，前提是这些消息发往同一台服务器的同一个分区。为了实现这一点，你还需要实现自己的PartitionSelector用于固定选择分区

选择分区可以按照一定的业务逻辑来选择，如根据业务id来取模。或者如果是传输文件，可以固定选择第n个分区使用。当然，如果传输文件，通常我们会建议你只配置一个分区，那也就无需选择了。

消息的顺序发送可以使用这个OrderedMessageProducer，自定义管理分区信息，并提供故障情况下的本地存储功能。

消息重复

消息的重复包含两个方面，生产者重复发送消息以及消费者重复消费消息。

针对生产者来说，有可能发生这种情况，生产者发送消息，等待服务器应答，这个时候发生网络故障，服务器实际已经将消息写入成功，但是由于网络故障没有返回应答。那么生产者会认为发送失败，则再次发送同一条消息，如果发送成功，则服务器实际存储两条相同的消息。这种由故障引起的重复，meta是无法避免的，因为meta不判断消息的data是否一致，因为它并不理解data的语义，而仅仅是作为载荷来传输。

针对消费者来说也有这个问题，消费者成功消费一条消息，但是此时断电，没有及时将前进后的offset存储起来，则下次启动的时候或者其他同个分组的消费者owner到这个分区的时候，会重复消费该条消息。这种情况meta也无法完全避免。

Meta对消息重复的保证只能说在正常情况下保证不重复，异常情况无法保证，这些限制是由远程调用的语义引起的，要做到完全不重复的代价很高，meta暂时不会考虑。

一下所述的问题，不仅是对ActiveMQ，对于其他的JMS也一样有效。

1.1 不要频繁的建立和关闭连接

JMS使用长连接方式，一个程序，只要和JMS服务器保持一个连接就可以了，不要频繁的建立和关闭连接。频繁的建立和关闭连接，对程序的性能影响还是很大的。这一点和jdbc还是不太一样的。

1.2 Connection的start()和stop()方法代价很高

JMS的Connection的start()和stop()方法代价很高，不能经常调用。我们试用的时候，写了个jms的connection pool，每次将connection取出pool时调用start()方法，归还时调用stop()方法，然而后来用jprofiler发现，一般的 cpu时间都耗在了这两个方法上。

1.3 start()后才能收消息

Connection的start()方法调用后，才能收到jms消息。如果不调用这个方法，能发出消息，但是一直收不到消息。不知道其它的jms服务器也是这样。

1.4 显示关闭Session

如果忘记了最后关闭Connection或Session对象，都会导致内存泄漏。这个在我测试的时候也发现了。本来以为关闭了 Connection，由这个Connection生成的Session也会被自动关闭，结果并非如此，Session并没有关闭，导致内存泄漏。所以一 定要显示的关闭Connection和Session。

1.5 对Session做对象池

对Session做对象池，而不是Connection。Session也是昂贵的对象，每次使用都新建和关闭，代价也非常高。而且后来我们发现， 原来Connection是线程安全的，而Session不是，所以后来改成了对Session做对象池，而只保留一个Connection。

2 集群

ActiveMQ有强大而灵活的集群功能，但是使用起来还是会有很多陷阱。

2.1 broker cluster和 master-slave

ActiveMQ可以做broker的集群，也可以做master-slave方式的集群。前者能在多个broker之前fail-over和 load-balance，但是在某个节点出故障时，可能导致消息丢失；而后者能实时备份消息，和fail-over，但是不能load- balance。broker cluser的方式，在一个broker上发送的消息可以在其它的broker上收到。当一个broker失效时，客户端可以自动的转到别的broker 上运行，多个broker可以同时提供服务，但是消息只存储在一个broker上，如果那个broker失效了，那么客户端直到它重新启动后才能收到该 broker上的消息，假如很不幸，那个broker的存储介质坏了，那么消息就丢失掉了。
Master-slave方式中，只有master提供服务，slave只是实时的备份master的数据，所以消息不会丢失。当master失效 时，slave会自动升为master，客户端会自动转到slave上工作，所以能fail-over。由于只有master提供服务，所以不能将负载分 到多个broker上。
其实单个broker的性能已经是相当的惊人了，在我们公司的机器上能达到每秒收发4000个消息，没个消息4K字节这样的速度，足够公司目前的需要了，而公司并不希望丢失任何数据，所以我们选择使用master-slave模式。

2.2 多种master-slave模式

master-slave也有多种实现方式。它们的不同只是在共享数据和锁机制上。

2.2.1 Pure master-slave

Pure master-slave，显示的在配置文件中指定一个broker做为另一个broker的slave。运行时，slave同过网络自动从master 出复制数据，同时在和master失去连接时自动升级为master。当master失效，slave成为master后，如果要让原先的master重 新投入运行，需要停掉运行中的slave(现在升级为master了)，手动复制slave中的数据到master中。再重新启动master和 slave。这种方式最简单，效率也不错，但是只能有两台做集群，只能fail-over一次，而且需要停机回复master-slave结构。

2.2.2 JDBC master-slave

这种方式不需要特殊的配置，只要让所有的节点都把数据存储到同一个数据库中。先拿到数据库表的锁的节点成为master，一旦它失效了，其它的节点 获得锁，就可以成为master。因为数据通过数据库共享，放在一个地方，不需要停机恢复master-slave。这种方式，需要额外的数据库服务器， 如果数据库失效了，那么就全失效了，而且速度不是很快。我们在用mysql测试时，并没有成功，master失效后，其他的节点始终没有升级成 slave，可能是数据库配置的问题。

2.2.3 Share file master-slave

这种方式类似于前者，也不需要特别的配置，只是通过共享文件系统来共享数据，靠文件锁实现只有一台成为master。共享文件系统的方式有很多，我们测试了nfs v4 (v3有bug，不行)， 最终在稳定性，效率等方面不是很满意，可能是通过网络太慢了。

测试过众多master-slave模式后发现，pure方式管理起来麻烦，jdbc方式成本高，效率低，share file方式需要高性能的共享文件，都有缺点。鉴于单台activeMQ很可靠，而我们的基础平台组愿意用硬件备份，最终还是决定不用master- slave了，也不用broker cluster，就用单台，通过硬件冗余保证数据不会丢失，并找另外一台刀片机做冷备，在主服务器失效时顶替。