【ActiveMQ Tuning】Serializing to Disk

标签: activemq tuning serializing | 发表时间:2012-07-24 11:23 | 作者:南郭先生kaka
出处:http://www.cnblogs.com/

     翻译自: http://fusesource.com/docs/broker/5.4/tuning/PersTuning-SerialToDisk.html

     KahaDB message store:KahaDB 是ActiveMQ Broker 为了高性能而推荐使用的消息存储机制。KahaDB支持多种性能选项供你进行调整,以获得最优性能。

Normal dispatching through a persistent broker(持久化Broker常规分发):Figure2.1 持久化Broker的常规分发步骤总览

    persist_02

       从Producer接收消息后,Broker会按照如下的几个步骤分发消息给消费者:

  1. Broker把消息存到Message Store中,如果 enableJournalDiskSyncs true,消息会在borker继续处理之前存储到磁盘上。
  2. 现在Broker发送消息给所有感兴趣的consumers,(但不需要等待Consumer的确认).Topics是立即发送,Queue则是由Broker增加消息到一个目标游标(Cursor)
  3. Broker给与Producer一个签收反馈。

Concurrent store and dispatch:为了提高Broker的性能,你可以设置 concurrent store and dispatch选项,允许存储消息和发送消息给消费者同时进行。

Figure 2.2图表展示了消息存储和分发的并行操作。(原文是2.1,个人感觉有错误)

Figure 2.2. Concurrent Store and Dispatch

 

 

persist_03

从Producer接收消息后,Broker会按照如下的几个步骤分发消息给消费者:

  1. Broker把消息存到Message Store中,同时,发送消息给所有感兴趣的消费者(consumer),发送完毕后,Broker会给与Producer一个签收反馈,而这个反馈不需要等待消费者的确认或者消息是否已经序列化到磁盘上。
  2. 一收到所有的消费者反馈后,Broker就把消息从消息存储中移除。consumer的反馈通常会比消息存到到磁盘上快,这就意味着消息存储到磁盘上的步骤会被优化掉。这是因为消息会在存储到磁盘之前就从消息存储中被移除掉了。

Configuring concurrent store and dispatch:concurrent store and dispatch 的特性在Queue和Topic分别由 concurrentStoreAndDispatchQueues concurrentStoreAndDispatchTopics 进行设置。Queue默认是设置为True,但是Topic则是false,如果需要设置为true,需要参照如下,配置Broker中kahaDB项:

  
<broker brokerName="broker" persistent="true" useShutdownHook="false">
  ...
  <persistenceAdapter>
    <kahaDB directory="activemq-data"
            journalMaxFileLength="32mb"
            concurrentStoreAndDispatchQueues="true"
            concurrentStoreAndDispatchTopics="true"
            />
  </persistenceAdapter>
</broker>

本文链接

相关 [activemq tuning serializing] 推荐:

【ActiveMQ Tuning】Serializing to Disk

- - 博客园_首页
     翻译自: http://fusesource.com/docs/broker/5.4/tuning/PersTuning-SerialToDisk.html.      KahaDB message store:KahaDB 是ActiveMQ Broker 为了高性能而推荐使用的消息存储机制.

【ActiveMQ Tuning】Prefetch Limit

- - 博客园_首页
   摘要:ActiveMQ优化 客户端优化 预取限制. 原文: http://fusesource.com/docs/broker/5.4/tuning/GenTuning-Consumer-Prefetch.html. Overview:图列4.1阐明了Broker在等待之前发送给客户端消息的反馈的行为.

Elasticsearch Performance Tuning Practice at eBay

- -
Elasticsearch is an open source search and analytic engine based on Apache Lucene that allows users to store, search, analyze data in near real time. This document summarizes the challenges as well as the process and tools that the Pronto team builds to address the challenges in a strategic way.

ActiveMQ 桥接

- - CSDN博客互联网推荐文章
使用目的:将本地产生的消息转发到远程,通过远程服务器来处理消息,处理完成后,再启动消费者处理本地服务器消息(验证消息是否被转走,本地无消息可处理为正常). 消息在下面的地址被消费,无需任何特别配置,采用默认的配置即可. 生产消息地址为localhost:7001,需要做如下配置. 注意: 表示只有这个队列的会进行桥接转发.

ActiveMQ学习小结

- - CSDN博客架构设计推荐文章
   Activemq是众多开源消息中间件的一种,支持集群,同等网络,自动检测,TCP,SSL,广播,持久化,和J2EE1.4容器无缝结合. 它是apache基金会的一个项目,而且经过多年发展,有了很高的稳定性. 目前被很多知名项目使用,比如Apache serviceMix、FuseESB.  消息中间件一般被用在异步消息通信、整合多个系统的场景,比如你注册CSDN论坛,你填写完注册信息点提交时,它会发一份验证邮箱的验证邮件给到你,这封邮件就可以通过消息中间异步发送给你.

ActiveMQ与Spring整合

- - 博客园_首页
ActiveMQ 是Apache出品, 是最流行​​和最强大的开源消息总线. 同时完全支持 JMS 1.1和J2EE 1.4规范. 支持多种编程语言和协议编写客户端. 在JMS客户端和消息代理完全支持企业集成模式. 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务). 对Spring的支持, ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性.

ActiveMQ高级特性

- - zzm
消息生产者使用持久(persistent)传递模式发送消息的时候,Producer.send() 方法会被阻塞,直到 broker 发送一个确认消息给生产者,这个确认消息暗示生产者 broker 已经成功地将它发送的消息路由到目标目的并把消息保存到二级存储中. 但有一个例外,当发送方法在一个事物上下文中时,被阻塞的是commit 方法而不是 send 方法.

宇宙微調論證(fine-tuning argument)

- Calon - 哲學哲學雞蛋糕.
這麼扯的事情竟然會發生,這只能用神蹟來解釋. 」許多人使用這種「奇蹟論證」的格式來建立支持上帝存在的主張,這些主張的不同之處,大致上在於它們訴諸不同的「神蹟」. 有些人相信上帝(或土地公,whatever)存在,因為若不是這樣,他沒有辦法解釋自己的某些奇特經歷(例如摔倒之後腦瘤就好了). 智慧設計論者相信萬物是神創的,因為他們不認為這些具備各種奇奇怪怪精細器官的動植物,能夠經由巧合自己蹦出來.

MySQL SQL Tuning:深入理解Order By

- - CSDN博客数据库推荐文章
在MySQL中ORDER BY按先后顺序有2种实现方式,先走索引无排序,如果不行,则用FILESORT. 走索引无排序需要满足2个条件:. ①排序字段和执行计划中所利用INDEX的索引键(或前面几个索引键)完全一致. ②表访问方式为index、ref或range [注释:explain输出中的Type可看出].

ActiveMQ持久化方式

- - CSDN博客架构设计推荐文章
消息持久性对于可靠消息传递来说应该是一种比较好的方法,有了消息持久化,即使发送者和接受者不是同时在线或者消息中心在发送者发送消息后宕机了,在消息中心重新启动后仍然可以将消息发送出去,如果把这种持久化和ReliableMessaging结合起来应该是很好的保证了消息的可靠传送. 消息持久性的原理很简单,就是在发送者将消息发送出去后,消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等,然后试图将消息发送给接收者,发送成功则将消息从存储中删除,失败则继续尝试.