kafka学习(七):消息队列与JMS
Apache Kafka是一个开源消息系统,由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目,目标是为处理实时数据提供一个统一、高通量、低等待的平台,Kafka被广泛地应用于各种流式计算中。
1、消息队列
我们可以把消息队列比作是一个存放消息的容器,当我们需要使用消息的时候可以取出消息供自己使用。
1.1、消息队列有什么用?
消息队列是分布式系统中重要的组件,使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。
1.2、消息队列的两种模式
点对点模式
应用程序由:消息队列,发送方,接收方组成。
每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,直到他们被消费或超时。
发布订阅模式
应用程序有由:主题(Topic)、发布者(Publisher)、订阅者(Subscriber)构成。
发布者发布一个消息,该消息通过topic传递给所有的客户端。该模式下,发布者与订阅者都是匿名的,即发布者与订阅者都不知道对方是谁。并且可以动态的发布与订阅Topic。
Topic主要用于保存和传递消息,且会一直保存消息直到消息被传递给客户端。
1.3、为什么需要消息队列
消息队列的核心作用就是三点:解耦一个系统中各个子模块的互相绑定与依赖,异步执行后台耗时逻辑,并行处理一个请求中涉及的多个操作。
以我们常见的下订单场景来说明,我们熟悉的淘宝,后台运作着成千上百的子系统,一个简单的加入购物车并下单的操作,后台要经过购物车存储记录,计费中心计算总值,订单中心处理订单,后转交仓库处理等等子系统的逻辑,如果每下单一件物品,都要等所有流程跑完,再返回下单成功的提示,那用户体验是极差的,因为在多个子系统的信息传递和处理会带来时间上的巨大开销。同时这样的架构设计也是不合理的,各个子系统会存在互相依赖甚至循环依赖的情况,在子系统日益增多的场景下,这样的一个庞大系统是难以维护的。
而我们现实的体验是,每次一点击下单,马上就返回了订单处理成功的提示。那是因为淘宝后台广泛的使用了消息中间件,将订单信息以消息的形式发送到MQ消息中间件。而后台所有子系统各自独立运作,通过收发消息来并行的对订单作存储,计费,入库,出库操作,这样极大的提高了系统的灵活性,减少用户等待提示的时间,带来了更好的用户体验。
2、JMS规范
JMS是什么:JMS是Java消息服务(Java Message Service)应用程序接口,是一个Java平台中关于面向消息中间件(MOM)的API,类似于JDBC。即:Java提供的一套技术规范和关于消息中间件的协议。
JMS干什么用:通过生产者Producer,消息服务器,以及消费者通力合作,使异构系统能进行集成通信,缓解系统瓶颈,提高系统的伸缩性增强系统用户体验,使得系统模块化和组件化变得可行并更加灵活,其中生产者,消息服务器,以及消费者的工作模型如下:
用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。它提供创建、发送、接收、读取消息的服务。由Sun公司和它的合作伙伴设计的应用程序接口和相应语法,使得Java程序能够和其他消息组件进行通信。
JMS是一个消息服务的标准或者说是规范,允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信,耦合度更低,消息服务更加可靠以及异步性。
介绍到这里,应该明白了消息队列和JMS的区别了吧?
消息队列:计算机科学中,A和B进行通信的一种方式。
JMS:java平台之间分布式通信的一种标准或者规范。
2.1、JMS的消息传输模型
点对点,发布订阅,消息队列中已经说的很清楚了,这里就不重复说了。
2.2、JMS核心组件
- Destination 消息发送的目的地。
- message 被发送的消息
- producer 消息的生产者,发送消息必须通过生产者来发送
- consumer 与生产者对应,这是消息的消费者和接收者,通过它来接收一个消息
接口名称 | p2p | pub/sub | 备注 |
---|---|---|---|
connectionFactory | queueConnectionFactory | TopicConnectionFactory | 基于工厂模式,创建和jms提供者之间的链接,需要制定链接的url和协议,任何jms客户端和jms提供者之间的交互,都必须要制定链接 |
Destination | queue | topic | ”目的地“ jms提供者用于标记消息所属类型的标记 |
connection | queueConnection | topicConnection | ”链接“用于描述一个具体的链接入udp和tcp,任何交互数据都需要通过这个链接进行,jms实现者定义数据格式(协议),在物理层用于区分jms客户端,一般而言,一个应用只有一个“链接”。 |
session | queueSession | topicSession | ”会话“,在逻辑上用于区分jms客户端,因为链接可被共用已提高网络利用率,每个session可以支持相对独立的事务和相关属性,每个session都有ID |
message | "消息",jms api中提供了多种message类型,它们有各自的”序列化/反序列化“机制;消息中可以包含多种jms属性以及客户端自定义的消息属性和内容 | ||
producer | queueSender | TopicPublisher | “生产者”,一种可以向jms提供者提交消息的客户端类型 |
consumer | queueReceiver | TopicSubscriber | ”消费者“一种可以向jms获取消息的客户端类型 |
2.3、JMS的可靠性
JMS提供了持续化/ack确认机制/事务 来保证消息的可靠性(防止消息丢失,消息的重复消费)
- 持久化
- 当服务宕机时,数据不丢失,会保存在服务器本地,持久化可以保证消息在未被消费方消费前不丢失,默认为持久化传送模式,保证消息只被传输一次和消费一次,可靠性是优先考虑因素。
- topic持久化,消费者需要在MQ注册一个自己的身份id标识,在消费者宕机时,生产者会为对应的id保留数据。
- 事务
- acid生产者消费者为了保证多条消息发送保证同步提交和同步消费,可以开启事务功能,需要提交事务,
- 从发送这角度来看,jms提供者为这组消息提供了高速缓存,知道执行commit为止,如果发生了故障或者执行了rollback操作,这些消息就会丢弃,在一个事务中传送给消息服务器的消息,它并不会转发给消费者,直到生产者生产完消息并执行了commit操作为止。
- 从消费者角度来看,jms支持事务的接收,jms提供者在提供这些消息给消费者时,消费者消费这些消息要么全部接收,要么一条也不接收,这些消息会尽快传给接收者,但是它们一直由jms提供者保存,直到接收者在会话对象上执行commit为止,如果发送发生了故障或者执行了rollback操作,提供者会试图重新发送消息,在这种情况下,这些消息会设置重新传送标记。
- ACK确认机制
- 1.自动ack消费者自动ack
- 2.手动ack 需要自己手动提交ack信息
- 3.运行重复签收,用于可以多消费者签收的消息
事务和ack都是消息确认的方式,同时存在时事务的优先级要高一些,开启事务时ack是无效的,非事务的模式下,ack开启才有效。
3、Kafka介绍
Apache Kafka是一个开源消息系统,由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目,目标是为处理实时数据提供一个统一、高通量、低等待的平台,Kafka被广泛地应用于各种流式计算中。
Kafka提供了类JMS的特性,但在设计实现上并不遵循JMS规范,Kafka对消息保存时根据Topic进行归类,发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)称为broker。同时无论是kafka集群,还是producer和consumer都依赖于zookeeper集群保存一些meta信息,来保证系统可用性。
Kafka核心组件及简单的运作流程图:
Topic :消息根据Topic进行归类
Producer:发送消息者
Consumer:消息接受者
Kafka cluster:kafka集群
broker:每个kafka实例(server)
Zookeeper:依赖集群保存meta信息
更多推荐
所有评论(0)