ActiveMQ 消息中间件报告

本文介绍了ActiveMQ消息中间件的基础知识,包括其安装启动过程、点对点与发布/订阅消息模型,并详细探讨了消息持久化的实现方式及消费者端的负载平衡策略。

ActiveMQ 消息中间件报告

                                                       简介

ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo,轻量级容器和任Java应用程序无缝的给合。

       下载地址 :http://activemq.apache.org

启动ActiveMq

下载ActiveMq (我用的是4.1版本)

解压 apache-activemq-4.1.1.zjip

在  apache-activemq-4.1.1\apache-activemq-4.1.1\bin 目录下有个activemq.bat,启动它即可。

点对点(point-to-point, P2P)

在 P2P 模型中,发送者分发消息到 queue (队列)中,queue 中的一条消息只能被一个接受者接收,接收者不需要在消息发送的同时监听该queue。消息会一直保存在队列里直到被取走。

发布/订阅(publish/subscribe, Pub-Sub)

       Pub-Sub消息模型是一对多的模型,即一条消息会被多个接收者接到。发布者将消息发送到topic,该topic 的所有活动订阅者将接收该消息。没有监听该topic的非活动订阅者将错过这个已发布的消息。如果没有监听该topic的非活动订阅者也想接收到它订阅的、发布到该topic所有消息,可以使用消息持久化来实现。消息持久化将在下面介绍

消息持久化

       ActiveMQ很好的支持了消息的持久性(Persistence)。消息持久性对于可靠消息传递来说应该是一种比较好的方法,有了消息持久化,即使发送者和接受者不是同时在线或者消息中心在发送者发送消息后宕机了,在消息中心重新启动后仍然可以将消息发送出去。

      消息持久性的原理很简单,就是在发送者将消息发送出去后,消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等,然后试图将消息发送给接收者,发送成功则将消息从存储中删除,失败则继续尝试。消息中心启动以后首先要检查制定的存储位置,如果有未发送成功的消息,则需要把消息发送出去。  
      对于ActiveMQ,消息的持久化使用是很简单的,仅仅通过配置信息就可以实现。这里主要介绍两种不同的持久化方法。

 

l         High performance journal

      这是ActiveMQ基于开源的HOWL(High-speed ObjectWeb Logger),将HOWL扩展为可以存储任意大小的消息(HOWL只能存储固定大小的记录),实现的一种消息持久化方法。它可以快速的将消息存储在本地文件中,且这种文件是以一种类似数据库的方式管理的。这样,如果你发送了10,000个消息,可能只有很少数的消息没有发送成功,当达到一个 checkpoint的时候,journal将一批未成功消息通过JDBC存储到数据库,这样避免了多次的数据库操作,很大程度上提高了性能并且保证了可靠性。  
      配置方法非常简单,就是无需配置,呵呵。ActiveMQ默认支持Journal,在activemq.xml配置文件中,可以找到如下信息:

 

这里可以改动的就是journalLogFiles,这个属性是制定默认创建几个数据文件来存储消息。journalLogFileSize为数据文件大小,默认为20MB。dataDirectory指向了存储数据文件的位置。

 

l         使用Oracle进行消息持久化  
      ActiveMQ持久几乎所有数据库(因为是通过JDBC把消息存储到数据库的)。方法同样简单,就是配置信息稍微有点变化。

 

 

其中dataSource指定了所用数据源的名字为oracle-ds。需要在activemq.xml文件中的<broker>标签之外配置数据源。下面是oracle的配置信息。

 

这样,消息中心具有了消息持久化功能,还需要做的就是消息发送者在发送消息的时候要采用JMS中的PERSISTENT模式发送消息。示例代码如下:

消费者端负载平衡

       ActiveMQ 特性之一是可以在消费者端进行负载平衡,消息组是一种不太为人所知的 JMS 可选特性。“它有点儿像 Web 应用程序的负载平衡,但是应用于消息传递,假设我们将来自某站点的商品订单放进一个队列中,希望尽可能快地处理它们。JMS 提供者会在消费者之间根据负载平衡原则分配这些消息。

消息集群

       ActiveMQ支持多个 Broker集群,假设我们的Broker分别在不同节点上,消息发布者在创建连接的时候URL使用 “failover:url1,url2,url3”

    ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“failover:tcp:localhost:61616,tcp:192.168.10.5:61616”);

   

假设现在有 1组Broker,每个Broker都在不同的节点上,1个消息发布者,每个Broker对应两个消息接收者

 

1、  任意一个消息接收者停止都不会影响整个工作。

2、  如果有一个Broker停机,那么该Broker对应的消息接收者也会停止工作,这时候消息发送会阻塞,使用TransportListener 可以解决这个问题。

3、  ActiveMQ 多个Broker集群的负载均衡目前为止有些缺陷,即一个Broker停机后,如果该Broker对列里还有没有被消费者消费的消息,那么这些消息不会分发给其他broker,如果做了消息持久化,那么该broker再次启动后那些消息还可以被消费者消费.如果没有做持久化,消息会丢失。

官方文档上说 通过 Master Slave 方式集群可以解决这个问题,实现Master Slave集群可以通过

1 Pure Master Slave

Shared File System Master Slave

3 JDBC Master Slave

其中前两种需要硬件来配合,硬件价格是相当昂贵的

第3种是通过数据库存储实现,这样会给数据库造成很大的压力,而且当前对mysql数据库的支持不是很好(测试过)

 

总之,经过了一段时间的研究和测试,发现 ActiveMq 还不是特别成熟,对于单点故障不能做很好的处理。于是我们换 jobss jms集群了,经过测试后发现比ActiveMQ要稳定,不过对于单点故障的处理也有些缺陷。单点故障好像是个死穴,呵呵。

 

转载地址:http://blog.sina.com.cn/s/blog_4d720f0701000b35.html

内容概要:本文系统介绍了算术优化算法(AOA)的基本原理、核心思想及Python实现方法,并通过图像分割的实际案例展示了其应用价值。AOA是一种基于种群的元启发式算法,其核心思想来源于四则运算,利用乘除运算进行全局勘探,加减运算进行局部开发,通过数学优化器加速函数(MOA)和数学优化概率(MOP)动态控制搜索过程,在全局探索与局部开发之间实现平衡。文章详细解析了算法的初始化、勘探与开发阶段的更新策略,并提供了完整的Python代码实现,结合Rastrigin函数进行测试验证。进一步地,以Flask框架搭建前后端分离系统,将AOA应用于图像分割任务,展示了其在实际工程中的可行性与高效性。最后,通过收敛速度、寻优精度等指标评估算法性能,并提出自适应参数调整、模型优化和并行计算等改进策略。; 适合人群:具备一定Python编程基础和优化算法基础知识的高校学生、科研人员及工程技术人员,尤其适合从事人工智能、图像处理、智能优化等领域的从业者;; 使用场景及目标:①理解元启发式算法的设计思想与实现机制;②掌握AOA在函数优化、图像分割等实际问题中的建模与求解方法;③学习如何将优化算法集成到Web系统中实现工程化应用;④为算法性能评估与改进提供实践参考; 阅读建议:建议读者结合代码逐行调试,深入理解算法流程中MOA与MOP的作用机制,尝试在不同测试函数上运行算法以观察性能差异,并可进一步扩展图像分割模块,引入更复杂的预处理或后处理技术以提升分割效果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值