• 1. JMS简介:Java 消息服务(Java Message Service,简称JMS)是用于访问企业消息系统的开发商中立的API。与JDBC很相似,提供了独立于特定厂商的企业消息系统访问方式JMS编程:应用程序A 发送一条消息到消息服务器的某个目得地(Destination),然后消息服务器把消息转发给应用程序B消息组成: 头,每条JMS 消息都必须具有消息头,包含用于路由和识别消息的值 属性,消息可以包含称作属性的可选头字段。他们是以属性名和属性值对的形式制定的。可以将属性是为消息头的扩展 主体,包含要发送给接收应用程序的内容。每个消息接口特定于它所支持的内容类型
  • 2. JMS-消息传递模型点对点消息传递1、一个队列可以关联多个队列发送方和接收方,但一条消息仅传递给一个接收方。 2、如果多个接收方正在监听队列上的消息,JMS Provider将根据“先来者优先”的原则确定由哪个消费端接受下一条消息。 3、如果没有接收方在监听队列,消息将保留在队列中,直至接收方连接到队列为止。这种消息传递模型是传统意义上的拉模型或轮询模型。 4、在此列模型中,消息不是自动推动给客户端的,而是要由客户端从队列中请求获得
  • 3. JMS-消息传递模型发布/订阅消息传递1、过发布/订阅消息传递模型,应用程序能够将一条消息发送到多个接收方 2、允许多个主题订阅者接收同一条消息。JMS一直保留消息,直至所有主题订阅者都接收到消息为止 3、推模型。在该模型中,消息会自动广播,消费者无须通过主动请求或轮询主题的方法来获得新的消息。
  • 4. activemq1. 实现JMS1.1规范,支持J2EE1.4以上。 2. 可运行与任何JVM和大部分web容器(ActiveMQ works great in any JVM) 3. 支持多种语言客户端(java, C, C++, Ajax, ActionScript等等) 4. 支持多种协议(stomp, openwire, REST) 5. 良好的Spring支持(ActiveMQ has great Spring Support) 6. 速度很快,JBossMQ的十倍(ActiveMQ is very fast; often 10x faster than JBossMQ) 7. 与OpenJMS、JBossMQ等开源jms provider相比,ActiveMQ有apache的支持,持续发展的优势明显
  • 5. Activemq-工作原理队列:是消息的安全存放地,队列存储消息直到它被应用程序处理。 队列管理器:是MQ系统中最上层的一个概念,由它为我们提供基于队列的消息服务 通道:是MQ系统中队列管理器之间传递消息的管道,它是建立在物理的网络连接之上的一个逻辑概念,也是MQ产品的精华
  • 6. Activemq-存储默认的activemq消息存储是通过一个所谓的AMQ Message Store来完成。 AMQ Message Store是一个高效的可嵌入支持事务的消息存储解决方案。 在此方案下消息(Message)本身以日志的形式实现持久化,存放在Data Log里。并且还对日志里的消息做了引用索引,方便快速取回Message。 一般情况下消息索引存放于内存(Cache)中,MQ Server定期将索引内容持久化,存放到Reference Store。 Message Data Log文件是有容量限制的,默认是32MB,可自行配置容量。当该Data Log文件里所有消息都被消费完的时候,Data Log文件就会被加上一个标记,通知下一次消息清理时可以被处理掉(处理方式可以是delete或是转移到Achieve目录)。
  • 7. Activemq-通讯模式点对点通讯:点对点方式是最为传统和常见的通讯方式,它支持一对一、一对多、多对多、多对一等多种配置方式,支持树状、网状等多种拓扑结构。  多点广播:即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点,并确保为每一站点可靠地提供信息。 发布/订阅(Publish/Subscribe)模式:使消息的分发可以突破目的队列地理指向的限制,使消息按照特定的主题甚至内容进行分发,用户或应用程序可以根据主题或内容接收到所需要的消息 群集(Cluster):群集类似于一个域(Domain),群集内部的队列管理器之间通讯时,不需要两两之间建立消息通道,而是采用群集(Cluster)通道与其它成员通讯,从而大大简化了系统配置。此外,群集中的队列管理器之间能够自动进行负载均衡,当某一队列管理器出现故障时,其它队列管理器可以接管它的工作,从而大大提高系统的高可靠性。
  • 8. Kafka-简介Kafka是一种分布式的,基于发布/订阅的消息系统。 主要设计目标如下: 1、以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间复杂度的访问性能 2、高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输 3、支持Kafka Server间的消息分区,及分布式消费,同时保证每个Partition内的消息顺序传输 4、同时支持离线数据处理和实时数据处理
  • 9. Kafka-架构Broker:Kafka集群包含一个或多个服务器,这种服务器被称为broker Topic:每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic。(物理上不同Topic的消息分开存储,逻辑上一个Topic的消息虽然保存于一个或多个broker上) Parition :Parition是物理上的概念,每个Topic包含一个或多个Partition
  • 10. Kafka-特性无状态broker 1.  Broker没有副本机制,一旦broker宕机,该broker的消息将都不可用,即消息丢失 2.  Broker不保存订阅者的状态,由订阅者自己保存。 3.  无状态导致消息的删除成为难题(可能删除的消息正在被订阅),kafka采用基于时间的SLA(服务水平保证),消息保存一定时间(通常为7天)后会被删除。 4.  消息订阅者可以rewind back到任意位置重新进行消费,当订阅者故障时,可以选择最小的offset进行重新读取消费消息。 高效的数据传输 1.  发布者每次可发布多条消息(将消息加到一个消息集合中发布), sub每次迭代一条消息。 2.  不创建单独的cache,使用系统的page cache。发布者顺序发布,订阅者通常比发布者滞后一点点,直接使用linux的page cache效果也比较后,同时减少了cache管理及垃圾收集的开销。 3.  使用sendfile优化网络传输,减少一次内存拷贝。 消息交付保证 1. kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。 2. kafka提供at-least-once delivery,即当consumer宕机后,有些消息可能会被重复delivery。 3. 因每个partition只会被consumer group内的一个consumer消费,故kafka保证每个partition内的消息会被顺序的订阅。 4. Kafka为每条消息为每条消息计算CRC校验,用于错误检测,crc校验不通过的消息会直接被丢弃掉。  
  • 11. Metaq-简介MetaQ(全称Metamorphosis)是一个高性能、高可用、可扩展的分布式消息中间件,思路起源于LinkedIn的Kafka,但并不是Kafka的一个Copy。MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用于大吞吐量、顺序消息、广播和日志数据传输等场景,目前在淘宝和支付宝有着广泛的应用。 可以说MetaQ是Apache Kafka的Java实现 & 功能增强版本
  • 12. Metaq-特性Meta相对于kafka特有的一些功能: 文本协议设计,非常透明,支持类似memcached stats的协议来监控broker 纯Java实现,从通讯到存储,从client到server都是重新实现。 提供事务支持,包括本地事务和XA分布式事务 支持HA复制,包括异步复制和同步复制,保证消息的可靠性 支持异步发送消息 消费消息失败,支持本地恢复 多种offset存储支持,数据库、磁盘、zookeeper,可自定义实现 支持group commit,提升数据可靠性和吞吐量。 支持消息广播模式 一系列配套项目:python客户端、twitter storm的spout、tail4j等。 Meta适合的应用: 日志传输,高吞吐量的日志传输本来就是kafka的强项 消息广播功能,如广播缓存配置失效。 数据的顺序同步功能,如mysql binlog复制 分布式环境下(broker,producer,consumer都为集群)的消息路由,对顺序和可靠性有极高要求的场景。 作为一般MQ来使用的其他功能
  • 13. MQ对比产品事务性简介ActiveMQ 支持 ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线 1、完全支持JMS1.1和J2EE 1.4规范 2、 多种语言和协议编写客户端 3、从设计上保证了高性能的集群,客户端-服务器,点对点优点: 成熟的产品,有较多的文档。各种协议支持较好,有多重语言的成熟的客户端; 缺点: 根据其他用户反馈,会出莫名其妙的问题,且会丢失消息。 其重心放到activemq6.0 产品上去了,目前社区不活跃,且对 5.x 维护较少;Activemq 不适合用于上千个队列的应用场景 metaq支持 1、是一个开源的、高性能、高可用、可扩展的分布式消息中间件 2、具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用于大吞吐量、顺序消息、广播和日志数据传输等场景,目前在淘宝和支付宝有着广泛的应用。 优点: 模型简单,接口易用在阿里大规模应用。目前淘宝、支付宝均使用。集群规模大概在50 台左右,单日处理消息上百亿;性能非常好,可以大量堆积消息在broker 中;支持多种消费,包括集群消费、广播消费等。开发度较活跃,版本更新很快。 缺点: 没有在 mq 核心中去实现JMS 等接口,对已有系统而言不能兼容。 阿里内部还有一套未开源的 MQ API,这一层API可以将上层应用和下层 MQ 的实现解耦,使得下面mq可以很方便的进行切换和升级而对应用无任何影响,目前这一套东西未开源 kafka不支持 Kafka 是LinkedIn 开发的一个高性能、分布式的消息系统,广泛用于日志收集、流式数据处理、在线和离线消息分发等场景优点:分布式可高可扩展,Kafka 集群可以透明的扩展,增加新的服务器进集群,高性能,Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ 实现,尤其是Kafka 还支持batch 操作 缺点:重复消息,Kafka 只保证每个消息至少会送达一次,虽然几率很小,但一条消息有可能会被送达多次。 消息乱序,虽然一个Partition 内部的消息是保证有序的,但是如果一个Topic 有多个Partition,Partition 之间的消息送达不保证有序。 复杂性,Kafka需要zookeeper 集群的支持,Topic通常需要人工来创建,部署和维护较一般消息队列成本更高
  • 14. MQ对比测试生产者测试:8个2GHz核,16GB内存,6个Raid10磁盘。使用1Gb网络 对比数值kafka至少是RabbitMQ的两倍,是ActiveMQ的一个数量级。 一个是因为kafka无需ack,另一个是因为kafka消息头很小,9bytes,而ActiveMQ由于JMS协议使其头较大144bytes。
  • 15. MQ对比测试消费者测试:8个2GHz核,16GB内存,6个Raid10磁盘。使用1Gb网络 一个消费者1千万的消息。同时设置RabbitMq和activeMq的acknowledge为自动。 从平均值来看,kafka消费大约是ActiveMQ和RabbitMQ的4倍。 这由于以下原因:kafka的存储格式更有效,传输数据少,另一个原因是ActiveMQ和RabbitMQ都需要维护每个消息发送后的交付状态。
  • 16. 感谢大家的聆听!