• kafka学习(七):消息队列与JMS


    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 与生产者对应,这是消息的消费者和接收者,通过它来接收一个消息

     

    接口名称p2ppub/sub备注
    connectionFactoryqueueConnectionFactoryTopicConnectionFactory基于工厂模式,创建和jms提供者之间的链接,需要制定链接的url和协议,任何jms客户端和jms提供者之间的交互,都必须要制定链接
    Destinationqueuetopic”目的地“ jms提供者用于标记消息所属类型的标记
    connectionqueueConnectiontopicConnection”链接“用于描述一个具体的链接入udp和tcp,任何交互数据都需要通过这个链接进行,jms实现者定义数据格式(协议),在物理层用于区分jms客户端,一般而言,一个应用只有一个“链接”。
    sessionqueueSessiontopicSession”会话“,在逻辑上用于区分jms客户端,因为链接可被共用已提高网络利用率,每个session可以支持相对独立的事务和相关属性,每个session都有ID
    message"消息",jms api中提供了多种message类型,它们有各自的”序列化/反序列化“机制;消息中可以包含多种jms属性以及客户端自定义的消息属性和内容
    producerqueueSenderTopicPublisher“生产者”,一种可以向jms提供者提交消息的客户端类型
    consumerqueueReceiverTopicSubscriber”消费者“一种可以向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信息

      

  • 相关阅读:
    【数据结构】八大经典排序(两万字大总结)
    【Dubbo3高级特性】「系统级别检查」服务端和消费端启动时检查
    Python综合案例(动态柱状图)
    STA series --- 8.Timing Verification (PARTII)
    【无标题】lllll
    记一次 .NET某工控自动化系统 崩溃分析
    Linux 远程联机服务(二)- Rsh服务器
    springBoot--web--路径匹配
    从一坨代码说起
    Flask 专题
  • 原文地址:https://blog.csdn.net/weixin_40482816/article/details/128014773