义马网站开发,做化工的 有那些网站,百度推广网站备案,wordpress添加水印有必要MQTT发布/订阅架构#xff08;Pub/Sub#xff09;
本文中#xff0c;将深入研究Pub/Sub架构#xff0c;在软件架构中一个消息模式#xff0c;它支持不同组件或系统之间以解耦的方式进行通信。 在前一片文章[MQTT简介]http://t.csdnimg.cn/6lNeZ中#xff0c;对MQTT有一个…MQTT发布/订阅架构Pub/Sub
本文中将深入研究Pub/Sub架构在软件架构中一个消息模式它支持不同组件或系统之间以解耦的方式进行通信。 在前一片文章[MQTT简介]http://t.csdnimg.cn/6lNeZ中对MQTT有一个整体的理解。现在来探究Pub/Sub模型对IoT应用的好处以及各种消息过滤技术理解MQTT、Pub/Sub和消息队列之间的区别。为了做好准备工作我们通过清晰定义发布/订阅模式做为开始。
MQTT发布/订阅Pub/Sub架构
在发布/订阅架构中有产生消息的发布者和接收消息的订阅者。但是发布-订阅是一个宽泛的概念有请多技术或协议可以实现。 MQTT就是这样一种遵循发布-订阅架构的特定消息传递协议。MQTT使用一种以代理为基础的模型客户端可以连接到代理消息被发送到主题。订阅者然后可以订阅指定的主题然后接收被发布的消息。 MQTT发布/订阅的解耦功能
相对于传统的客户端-服务端请求-响应模型发布/订阅架构提供了一种独特的替代方案。在请求-响应方式中客户端直接和服务端通信从而会造成降低性能的瓶颈。另外发布/订阅模型解耦了消息的发布者和订阅者。发布者和订阅者并不关心对方的存在。作为一个第三方代理处理处理他们之间的连接。这种解耦产生了一种更快速、更高效的通信流程。 通过消除发布者和订阅者之间直接通信的需要发布/订阅架构消除了IP和端口的交换。它还提供解耦功能允许两个组件上的操作在发布或接收期间连续通信而不间断。发布/订阅具有三个维度的解耦功能以实现最佳效率
空间解耦 发布者和订阅者无需知道对方的存在。时间解耦 发布者和订阅者无需在同一时间运行。同步解耦 在发布或接收过程中不需要中断两个组件的操作。 在MQTT协议中的解耦 MQTT从空间上将发布者和订阅者解耦这就意味着它们只需要知道代理的主机名称或IP及端口就可以发布和接收消息。另外MQTT在时间上进行解耦允许代理为不在线的客户端存储消息。必须满足两个条件来存储数据客户端必须已经连接代理并订阅了QoS大于0的主题。 发布/订阅软件架构最重要的一个优点是能够过滤所有消息并准确的分发给订阅者消除了发布者和订阅者要知道对方存在的需要。
发布/订阅消息的过滤功能
消息过滤功能是发布/订阅架构中非常重要的一个方面因为这可以使订阅者只接收它们关心的消息。发布/订阅代理broker提供了几种过滤选择包括基于主题的过滤、基于内容的过滤和基于类型的过滤。
选择1基于主题的过滤
这是最常用的过滤选择代理通过主题topic过滤消息。客户端通过主题订阅它们感兴趣的消息而代理通过主题层次结构将消息路由到相应的订阅者。主题的结构是有层级的通过斜杠/分层允许订阅者接收与特定主题级别或主题层级结构匹配的消息。下面是一个主题层级示例
优点
简单易用灵活允许分层主题结构高效因为只将消息发送给对特定主题感兴趣的订阅者。
缺点
发布者和订阅者要提前约定好主题的分层格式。仅能根据主题层级过滤消息。
用例
基于主题的过滤最适合于订阅者对主题特定子集感兴趣的场景。比如在一个智能家居系统中订阅者可能对某个房间的温度变化感兴趣那该订阅者会订阅一个类似smart-home/living-root/temperature的主题然后代理broker就只会发送匹配这个主题的消息给订阅者。 MQTT使用基于主题的方式过滤消息。每个消息都对应一个主题代理基于此确定订阅者是否接收该消息。关于主题的更多内容会在后续章节介绍。为了处理发布/订阅中的一些业务MQTT有三个QoS等级前面章节介绍过基于此MQTT可以轻松处理客户端发送消息到代理或代理推送消息到客户端。但是有一种可能没有订阅者订阅某个主题此时代理要知道如何处理这种情况。不同的代理软件有不同的处理机制。 为了保证层级主题的灵活性认真设计主题层级树非常重要要给未来的情况保留空间遵循这个策略MQTT会非常适合生产环境。 选择2基于内容的过滤
在这种过滤类型中代理broker使用过滤表达式基于消息的内容进行过滤。订阅者通过订阅一个指定的过滤表达式来表明它们感兴趣的消息代理基于消息内容将消息路由给合适的订阅者。 这种过滤模式要根据具体的代理broker进行处理不同的代理处理方式可能不一样。 优点
提供更多的控制粒度来接收消息。允许基于消息内容过滤而不仅仅是主题层级。灵活允许复杂的过滤表达式。
缺点
和基于主题的过滤相比使用起来更加复杂。发送者需要在消息中增加额外的元数据来支持过滤。处理大量筛选表达式时性能可能会受影响。
用例
最适用于消息未按主题组织且订阅者根据消息内容对特定消息子集感兴趣的场景。 比如在物流应用中订阅者只对包含某个指定单号的消息感兴趣则该订阅者就会订阅一个过滤表达式例如tracking-number123456代理broker就只会发送匹配这个表达式的消息给订阅者。
选择3基于类型的过滤
该类型的过滤代理broker通过消息的类型过滤消息。当和面向对象语言配合使用时消息被当作对象呈现出来这种过滤非常有用。订阅者通过订阅指定的消息类型来获取感兴趣的消息代理broker根据消息类型路由给订阅者。
优点
允许根据消息类型过滤不关心消息的主题和内容。易用特别是配合面向对象语言。更高的灵活性和扩展性。
缺点
只能通过消息类型过滤发布者和订阅者需要提前约定消息类型的层级。
用例
基于类型的过滤最适用于按类层级组织的消息和订阅者根据类对指定的类型或子类型感兴趣的消息。 比如在一个财务类应用中订阅者只对股票价格类型的消息感兴趣订阅者就会订阅“股票价格”类型的消息代理broker则只会发送此类消息给订阅者。
这些过滤选项在决定将哪些消息发送给哪些订阅者时提供了灵活性和粒度。根据用例可以使用这些过滤选项中的一个或多个来确保订阅者仅接收他们感兴趣的消息。 但是需要注意的是发布/订阅模型并不是适用于所有的情形有一些情况需要考虑比如在使用基于主题的过滤时需要确保发布和订阅双方知道使用哪一个主题。如何处理没有订阅者订阅消息。需要提前考虑待发布消息结构。 对基于主题的过滤发布者和订阅者需要提前知道使用哪个主题。另外对于消息发布发布者不能假设有人在订阅这个消息这是一个重要的点因为在发布/订阅模型中发布者将消息发布到代理broker并不知道订阅者是谁也不知道订阅是否连接到代理broker。代理负责将消息发送给所有订阅该主题的订阅者。但是如果没有该主题订阅者连接到代理broker则这消息永远都不会发送出去。因此对于消息发布者来说牢记消息发送是无法保证的并进行相应的系统设计是至关重要的。 MQTT发布/订阅的可扩展性
扩展性是发布/订阅架构的一个重要优点。传统的客户端-服务端模型在扩展性上存在局限特别是在处理大量客户端的情况下。但是在发布/订阅模型中代理broker能够以事件驱动的方式处理消息能够高并发操作这就意味着系统可以在不恓性性能的情况下处理高并发。 另外事件驱动处理中消息缓存和智能消息路由也有助于提高发布/订阅的可扩展性。通过缓存消息代理broker可以快速检索消息并将之发送给订阅者而无需额外的处理。另一方面智能路由确保消息只被发送给需要它们的订阅者减少不必要的网络拥堵使扩展性更佳。 MQTT遵循发布/订阅架构很自然的具体扩展性使之IoT应用场景的理想选择。尽管有这些优势扩展到支持成千上万个连接依然是个挑战。在这种场景下代理broker集群可以用来在多个服务器之间分配负载负载均衡器可以确保流量均匀分布。 现在我们已经对发布/订阅架构的基本概念有了一个认识接下来我们看下使用它对IoT通信的好处。
MQTT发布/订阅架构在IoT和IIoT中的主要优势是什么
发布/订阅架构有几个优势使之成为诸多应用的理想选择。这时列举一些主要优势
高可扩展性 发布/订阅架构具有高扩展性使之非常适合处理多客户端和多消息的应用。代理broker充当所有消息的中心枢纽能够在不影响性能的情况下处理请多客户端。强容错性 发布/订阅架构的解耦的特性同样提供了高容错性。在传统的客户端-服务端模型中如果服务端下线所有的客户端都会失去连接。相反在发布/订阅架构中代理broker可以存储消息直接客户关重新连接确认没有消息丢失。灵活性 发布/订阅架构很灵活可以用在各种应用中从低带宽、高延迟的网络环境到高速、低延迟的网络环境都可以。MQTT协议基于发布/订阅构架支持多个QoS等级为应用提供了灵活的选择性。
发布/订阅架构常见挑战和使用MQTT如何客服这些挑战
尽管发布/订阅架构有诸多上述优点但同样也有一些挑战必须处理才能确保成功的应用。下面列的是一些常见的挑战及处理方法
消息传递 使用发布/订阅架构的一个挑战是确保消息发送给订阅者在一些案例中一些特定的主题没有订阅者导致消息丢失。为了应用这个挑战MQTT提供了QoS。消息过滤 发布/订阅架构的另一个挑战是有效的消息过滤这样每个订阅者才能只接收自己感兴趣的消息。上文讨论过发布/订阅架构提供了三种过滤选项基于主题、基于内容和基于类型。每个类型都有其优点和缺点要结合自己的应用场景进行选择。MQTT使用基于主题的方式过滤消息每个消息都包含一个主题代理broker基于此来确定订阅者是否接收该消息。安全 在任何消息处理系统中安全都是一个非常重要的方面发布/订阅架构也不例外。MQTT允许提供了几种安全选项比如用户认证、接入控制和消息加密以保护系统免受未经授权的访问和数据泄漏。扩展性 发布/订阅架构的设计必须牢记扩展性因为在一个大系统中订阅者数量会呈指数级增长。MQTT提供了一些功能比如多代理结点、集群和负载均衡等来保证系统能够处理大量的订阅者和消息。消息排序 在发布/订阅系统中消息排序可能难以维护因为消息是异步发送的保证订阅都按照正确的顺序收到消息有一定的困难。但是MQTT提供了QoS来确保消息成功的从客户端发送到代理或从代理发送到客户端。 因为MQTT是异步工作的因此在等待或发布消息是不会阻塞任务。大多数客户端库都基于回调或类似的模型因此消息流通常是异步的。在一些案例中同步是可取的也是可能的。一些库有同步API来等待指定的消息。 **实时约束**在一些案例中要求严格的实时性则发布/订阅架构就不是最好的选择。如果低延迟非常关键则请求-响应模型架构是一个更好的选择。
你可以通过完备的设计和实现来解决使用发布/订阅架构中的挑战。开发人员理解了挑战可以构建出可扩展、安全、高效的消息系统有效的利用MQTT的功能。
MQTT VS 消息队列
关于MQTT有很多疑惑该协议是否是消息队列的一个实现这里会阐明该主题并解释其中的差异。在前一篇文章http://t.csdnimg.cn/HhjzK中提到MQTT指的是IBM的MQ系统产品与“消息队列”无关。无论名字的由来了解MQTT和传统消息队列之间的区别都很有用
一个消息队列存储消息直到该消息被消费掉。 当你使用消息队列时每条消息都被存储到队列直接被一个客户端消费者接收如果没有客户端接收该消息该消息则就停留在队列中等待被消费。在一个消息队列中一条消息不被任何客户端接收是不可能的。一个消息仅被一个客户端消息。 另一个在的不同点就是在传统的消息队列中一条消息仅能被一个客户端消费负载在队列的所有使用者之间分配。在MQTT中该行为正好相反每个订阅了该主题的订阅者都可以获取消息。队列有名称且必须被明确的创建。 队列比主题要严格很多。在一个队列可以使用之前该队列必须使用单独的命令显式创建。只有队列被命名和创建之后才有可能发布或消费消息。相反MQTT主题就非常灵活可以随时创建。 如果还有其他不同点可以在评论里交流。
总结
发布/订阅架构提供了一个灵活、可扩展的方式来构建分布式系统可以处理许多的客户端连接。MQTT的轻是级和高效的发布/订阅消息特性帮助它在IoT、移动和其他分布式应用程序得到广泛应用。 使用MQTT架构师和公司可以构建系统在各种实际场景中可靠、高效地传输数据。通过其空间和时间上的解耦、异步消息、基于主题的过滤和QoS等级等特性MQTT提供了一组强大的功能来帮助开发人员克服构建分布式系统的挑战。总之发布/订阅架构和MQTT协议是想要开发高效、可扩展分布式系统开发人员的有效工具。 在后续章节中将会近距离的探究MQTT客户端和代理broker的构建及两者之间如何连接。
