订阅者未主动接收已发布消息

是指在发布-订阅模式中，订阅者没有主动接收到已经发布的消息。发布-订阅模式是一种消息传递模式，用于解耦消息的发送者和接收者。

在发布-订阅模式中，发布者负责发送消息，而订阅者负责接收并处理消息。发布者将消息发布到一个消息队列（或者称为主题），订阅者可以通过订阅相应的主题来接收消息。当发布者发送消息后，如果订阅者没有主动去接收已发布的消息，那么这些消息就会一直保留在消息队列中，直到有订阅者来接收。

这种模式具有以下优势：

解耦性：发布者和订阅者之间通过消息队列进行通信，彼此之间不需要知道对方的存在，从而实现了解耦。
异步性：发布者可以通过消息队列异步发送消息，而不需要等待订阅者的响应，提高了系统的响应速度。
可靠性：消息队列具备消息持久化和高可用性的特性，即使订阅者在某些时候不可用，也不会丢失已发布的消息。

应用场景：

实时数据处理：可以用于处理实时生成的数据，例如日志收集、用户活动跟踪等。
事件驱动系统：可以用于构建事件驱动的架构，例如微服务架构中的消息通信。
分布式系统协调：可以用于在分布式系统中进行任务调度和协调。

腾讯云相关产品推荐：腾讯云消息队列 CMQ（Cloud Message Queue）是一种高可用、高可靠、分布式的消息队列服务，适用于各类场景的消息通信。它提供了多种消息传输模式和多种消息协议，支持海量消息堆积和可靠的消息投递。

产品介绍链接地址：https://cloud.tencent.com/product/cmq

相关·内容

【Redis】Redis 发布订阅通信模式 ( 发布订阅模式 | 订阅频道 | 发布消息 | 接收消息 )

文章目录一、发布订阅模式二、订阅频道三、发布消息四、接收消息一、发布订阅模式 ---- Redis 中存在一种发布订阅消息通信模式 : 消息发布者 : 负责发送消息 , 订阅者需要订阅该发布者频道...; 消息订阅者 : 负责接收消息 ; 订阅者先订阅发布者频道 , 当发布者发布消息时 , 订阅者会接收到该信息 ; 在 Redis 中 , 发布者是消息频道 , 订阅者是 Redis...客户端 ; 一个 Redis 客户端可以订阅多个消息频道 ; 一个消息频道可以被多个 Redis 客户端订阅 ; 当消息频道发送消息后 , 订阅该频道的客户端 , 就会收到该频道发送的消息...(integer) 1 127.0.0.1:6379> 四、接收消息 ---- 命令行 1 中 , 执行 subscribe channel1 命令 , 订阅了 channel1 频道 ; 命令行...2 中 , 执行 publish channel1 hello 命令 , 向 channel1 频道发送了 hello 消息 ; 然后在命令行 1 中 , 接收到了 hello 消息 ; 代码示例 :

1.7K2 0

邪恶GPT再添一员：暗网已超3000订阅，发布者身份成谜！

并且截止目前，暗网上已存在了超过3000条确认的订阅信息及评论。最顶级的犯罪工具根据发布者“Canadiankingpin”分享的截图，FraudGPT被描述为迄今为止最顶级的“AI工具”。...除此之外，根据发布者的介绍，FraudGPT还精通创建针对特定漏洞或目标的攻击软件，并能够帮助用户搜索互联网中隐藏的其他黑客组织、暗网以及用于交易被盗数据的网络黑市，亦或是为用户提供高质量的诈骗指南以及黑客技术学习资源...而另一个令人感到沮丧的消息是，在经历了近一周的研究后，Netrich也并未能够实现对FraudGPT背后的大语言模型的破解。...虽然自FraudGPT发布仅过去了不到两周，但一个明显的事实是，这款“顶级AI工具”已开始被利用到了实际的犯罪行为中。...七月中旬，国家网信办已联合六部门发布了《生成式人工智能服务管理暂行办法》；而在七月底，美国七家AI巨头也与白宫达成协议，将为AI生成内容添加水印。

5043 0

从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结

非直接传递消息的一方被称为「发布者」，接受消息处理称为「订阅者」。发布者将不同的消息进行分类后分发给对应类型的订阅者，完成消息的传递。...应用订阅分发机制的优势为便于统一管理，可以添加不同的拦截器来处理消息解析、消息过滤、异常处理机制及数据采集工作。 3.2.1 消息订阅业务层只专注于消息处理，并不关心消息接收分发的过程。...订阅的意义在于更好地将业务处理和数据通道处理解耦，业务层只需要订阅关注的消息类型，被动等待接收消息即可。 ?...订阅分发管理会根据各业务类型维护订阅者队列用于消息接收的分发操作。 3.2.2 消息分发数据通道的核心在于维护多消息类型各自对应的订阅者集合，并将解析的消息分发到业务层。 ?...而如通用消息如头像、名称、消息时间、是否可举报、已读未读状态、发送失败/重试状态等都可以统一处理，降低修改维护的成本，同时使各消息 UI 处理逻辑更少、更清晰，更利于新类型的扩展管理。

1.2K2 0

别人读没读你的消息，你如何知道？

1、如果群人数较多（公司有些群超过2000人），一条消息发出，返回的已读确认消息上千条，会直接把发送者的手机推死，流量、电量也消耗不起。 2、已读未读人数，只有发送者查看这条消息的时候才关心。...发送者如果在App上做别的事情，根本不需要关心当前有多少人已读。因此直接推送已读确认也不合适。如果变为客户端查看的时候主动拉取呢？...2、同时客户端向服务端请求订阅该条消息的回执消息（退出这个会话取消订阅） 3、服务端收到此消息的已读确认消息，向用户推送这样看似较完美，实际上仍然面临推消息的挑战。...我们注意到这类消息用户实际使用场景，用户只在需要查看这条消息已读情况的较短时间内关心已读未读数量。因此设置一个合理的主动拉取策略就可以比较好的解决这个问题，整个流程如下图。 ?...服务端进行未读人数计算，并缓存 2、User1在查看回执消息时，主动拉取已读人数或未读人数主动拉取策略怎么设置呢？用户查看回执消息时，20秒之内，每2秒拉取一次；如果用户退出会话则停止拉取。

1.8K2 0

ActiveMQ教程，详解ActiveMQ中Queue与Topic的区别

2、发布/订阅(publish/subscribe，简称pub/sub)Topic消息传递模型：通过该消息传递模型，应用程序能够将一条消息发送给多个消息消费者。...消息首先由消息生产者发布至消息服务器中特定的主题中，然后由消息服务器将消息传送至所有已订阅此主题的消费者。主题目标也支持长期订阅。...长期订阅表示消费者已注册了主题目标，但在消息到达目标时该消费者可以处于非活动状态。当消费者再次处于活动状态时，将会接收该消息。...如果消费者均没有注册某个主题目标，该主题只保留注册了长期订阅的非活动消费者的消息。与PTP消息传递模型不同，pub/sub消息传递模型允许多个主题订阅者接收同一条消息。...JMS一直保留消息，直至所有主题订阅者都接收到消息为止。pub/sub消息传递模型基本上是一个推模型。在该模型中，消息会自动广播，消息消费者无须通过主动请求或轮询主题的方法来获得新的消息。

1.2K3 0

MQTT心跳机制

byte10:Connect Flags 一个字节表示，除了第1位是保留未使用，其它7位都具有不同含义。业务上很重要，对消息总体流程影响很大，需要牢记。...这个遗嘱就是一个由客户端预先定义好的主题和对应消息，附加在CONNECT的可变头部中，在客户端连接出现异常的情况下，由服务器主动发布此消息。...也就是说，一旦客户端出现异常中断，便会触发服务器发布Will Message消息到Will Topic主题上去，通知Will Topic订阅者，对方因异常退出。...此时的关闭连接的行为和接收到客户端发送DISCONNECT消息的处理行为一致，但对客户端的订阅不会产生影响（不会清除客户端订阅数据），这个需要牢记。...有一点需要牢记，服务器在接收到客户端发送的DISCONNECT消息之后，需要主动关闭TCP/IP连接。

6.5K4 2

关于Pulsar与Kafka的一些比较和思考

发布者发布的每条消息仅存储在主题分区上一次，复制以存储在多个bookies（BookKeeper服务器）上，并且可以根据消费者的需要多次消费使用。...发生这种情况时，所有未确认的消息都将传递给新的主消费者，这类似于Apache Kafka中的使用者分区重新平衡。...另一方面，共享订阅允许每个主题分区有多个消费者，同一订阅中的每个消费者仅接收发布到主题分区的一部分消息。共享订阅最适用于不需要排序的并且可以扩展超出分区数量的使用者数量的队列用例。...Pulsar代理在接收消息确认时仅更新cursor,只有在所有订阅已经使用它之后才能删除消息（消息在其sorcor中标记为已确认）。...消息保留和消息TTL之间的区别在于消息保留适用于标记为已确认并将其设置为已删除的消息，保留是对主题应用的时间限制，而TTL适用于未使用的消息。因此，TTL是订阅消费的时间限制。

2.9K3 0

12.腾讯云物联网设备端学习---NTP功能及实现

简介 NTP功能.png ntp功能是简单的上下行topic配合的功能，设备端订阅下行主题，往上行主题发送消息，触发服务器下发下行消息，并根据下行消息进行处理。...，如果未订阅则订阅 _system_mqtt_get_resource_time_publish：向上行topic发布消息，去获取时间 _system_mqtt_result_wait：超时等待服务器回复...IOT_Sys_SyncNTPTime：和IOT_Sys_GetTime类似，区别在于会根据接收消息前后的时间通过HAL_Timer_SetSystimeSec和HAL_Timer_SetSystimeMs...源码实现（见system_mqtt.c），以下简单说明下这类服务的开发思路：同步订阅：大部分服务需要保证订阅的成功，为了保证订阅的成功，可以调用IOT_MQTT_SubscribeSync 消息处理：...，因为这部分内容是跟着mqtt client生命周期存在的，当mqtt client被销毁时，需要主动释放掉usr_data。

3K6 1

为什么会成为下一代的消息中间件之王？

1.5K3 0

颠覆Kafka的统治，新一代云原生消息系统Pulsar震撼来袭！

Pulsar是一个pub-sub (发布-订阅)模型的消息队列系统。...默认情况下，没有任何持久订阅的Topic的消息将被标记为已删除。如果要防止消息被标记为已删除，可以为此Topic创建持久订阅。在这种情况下，只有被确认的消息才会被标记为已删除。...如果Producer不能及时发布消息的所有分块，Consumer不能在消息的过期时间内接收到所有的分块，那么Consumer已接收到的分块消息就会过期。...因为消费者会为每个大消息在内存开辟一块缓冲区，以便将所有的块消息合并为原始的大消息。三、Pulsar消费者（Consumer） Consumer是通过订阅关系连接Topic，接收消息的程序。...（六）未确认的消息处理如果消息被消费者消费后一直没有确认怎么办？

7111 0

MQTT 5.0 协议之QoS 服务质量

发布者只会发布一次消息，接收者不会应答消息，发布者也不会储存和重发消息。消息在这个等级下具有最高的传输效率，但可能送达一次也可能根本没送达。...发布者会发布消息，并等待接收者的 PUBACK 报文的应答，如果在规定的时间内没有收到 PUBACK 的应答，发布者会将消息的 DUP 置为 1 并重发消息。...发布者发布 QoS 为 2 的消息之后，会将发布的消息储存起来并等待接收者回复 PUBREC 的消息，发送者收到 PUBREC 消息后，它就可以安全丢弃掉之前的发布消息，因为它已经知道接收者成功收到了消息...当接收者收到 PUBREL 消息之后，它会丢弃掉所有已保存的状态，并回复 PUBCOMP。无论在传输过程中何时出现丢包，发送端都负责重发上一条消息。...发布者和订阅者 MQTT 发布消息 QoS 不是端到端的，是客户端与服务器之间的。订阅者收到 MQTT 消息的 QoS 级别，最终取决于发布消息的 QoS 和主题订阅的 QoS。

4071 0

IM系统设计

订阅消息逻辑上一步连接成功后，用户触发进群（聊天窗口）操作，订阅该群消息。订阅消息用来保证，用户通过socket实时接收到该群其他用户发送的消息。否则，服务端会采用推送完成消息转发。订阅事件。...服务端判断该uid是否已经在线，如果已经在线，则主动关闭旧的Socket，保证只有当前窗口在线。并将当前socket句柄push到数组中保存。业务逻辑判断。群聊：判断用户是否属于该群，判断群合法性。...客户端在线，接收Socket消息，对消息解码，区分类型并展示。编码协议自定。客户端不在线，收到Push推送。客户端根据接收到的推送，拉取历史消息。更新未读数。...发布消息逻辑用户完成订阅群ID（群聊）或者订阅会话ID（私聊）后，可主动发送消息到该订阅ID（群ID和会话ID）中。发布事件。...写入队列，完成其他操作（判断图片色情内容，消息统计，落地入库，更新未读数）。群聊：遍历当前群存在的socket句柄，如果在线则转发内容，不在线推送通知。

3.6K8 1

5.0新特性

订阅选项第 2 位表示非本地选项(No Local)。如果值为 1，应用消息就不会发布给订阅发布主题的发布者本身，如果在共享订阅中将该选项设置为 1 的话，就会触发协议错误。...订阅选项的第 3 位表示保留为已发布(Retain As Published)。...若该值为 1，服务器须将转发消息的 RETAIN flag 设为与接收到的 PUBLISH 报文的 RETAIN flag 一致。...， 3 个值 0, 1, 2 分别代表订阅接收到的消息的最大 QoS 值。...(Disconnect with Will Message) DISCONNECT 16 0x10 没有匹配的订阅者 (No matching subscribers) PUBACK, PUBREC

1.9K2 0

Redis总结之发布订阅

绪论理论知识先介绍一下发布与订阅的基础知识： Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。...发布者不是直接将消息发送给特定的接收者（订阅者），而是将发布的消息分到不同的频道，不需要知道什么样的订阅者订阅。...订阅者支持订阅一个或多个频道，只需接收感兴趣的消息，不需要知道是由哪些发布者发布的。发布者和订阅者相对于频道channel而言，均可以理解为客户端。...客户端发到频道的消息，将会被推送到所有订阅此频道的客户端。客户端不需要主动去获取消息，只需要订阅频道，这个频道的内容就会被推送过来。 Redis 客户端可以订阅任意数量的频道。...缺点实践环节，大家注意到小编是先开启的订阅者客户端，有兴趣的伙伴可以实践一下如果先开启发布者客户端发布消息，订阅者是否能够收到消息，因此引出小编下面的内容：即使redis实现了发布订阅（publish

4833 0

比拼 Kafka , 大数据分析新秀 Pulsar 到底好在哪

通过队列模型，用户可以创建多个消费者从单个管道中接收消息；当一条消息从队列发送出来后，多个消费者中的只有一个（任何一个都有可能）接收和消费这条消息。...发布者发布的每条消息只在 Topic 中存储一次；存储的过程中，BookKeeper 会将消息复制存储在多个存储节点上；Topic 中的每条消息，可以根据消费者的订阅需求，多次被使用，每个订阅对应一个消费者组...消费者 B-0 和 B-1 通过订阅 B 订阅消费消息。B-0 是主消费者并接收所有消息。B-1 是故障转移消费者，如果消费者 B-0 出现故障，它将接管消费。...消息保留期消息 TTL 之间的区别在于：消息保留期作用于标记为已确认并设置为已删除的消息，而 TTL 作用于未 ack 的消息。上面的图例中说明了 Pulsar 中的 TTL。...例如，如果订阅 B 没有活动消费者，则在配置的 TTL 时间段过后，消息 M10 将自动标记为已确认，即使没有消费者实际读取该消息。 Pulsar VS.

6282 0

透析【观察者模式】和【发布订阅模式】

(dep) // 发布者把消息推给调度者 // 我是调度中心，我先把消息处理下先订阅者1 // 我是调度中心，我先把消息处理下先订阅者2 要点小结：写一个 Pub 发布者类，有添加调度中心 addDep...；实例化 1 个或多个调度的对象；实例化 1 个或多个订阅者对象；发布者绑定调度中心；调度中心绑定订阅者；发布者发布消息；由上面的例子可见，发布者不会把消息直接发给订阅者，而是会先发给调度中心...观察者模式中，被观察者直接把消息发给观察者，这是强绑定的，作为观察者，只有我主动绑定了我要观察的对象，我才能知道它发的消息给我；而在发布订阅模式中，发布者和订阅者是完全解耦的，作为发布者，我把消息发给调度中心之后...，我就不用管了，我只负责发布消息，不管谁接收；同样，订阅者，只负责接收调度中心来的消息，不用管是哪个发布者发的；高内聚、低耦合，是我们的最终追求！！...，然后去打印；做法2：用观察者模式设计思想，领导主动把这个电子稿以邮件形式群发给大家，让大家自行打印；如果稿件有内容变动的话，领导再主动推送给大家一份新的；做法3：用发布订阅者模式设计思想，领导发给秘书

3112 0

Redisson 分布式锁实现之前置篇 → Redis 的发布订阅与 Lua

/订阅　　官方文档：Redis Pub/Sub 　　什么是发布/订阅　　Redis 提供了基于 “发布 / 订阅” 模式的消息机制，此种模式下，消息发布者和订阅者不进行直接通信，发布者向指定的频道发布消息...四个角色：发布者（Pub）、订阅者（Sub）、对两者解耦的中间方（Channel）、消息（Message）　　　　Sub 订阅 Channel，Pub 向 Channel 发布消息（Message），...　　　　　　实际应用中，redis-cli 用的非常少，用的多的还是各种编程语言的 Redis 客户端　　　　2、新开启的订阅客户端，无法接收到该频道之前的消息，因为 Redis 不会持久化发布的消息...返回值： (integer) 1 表示有 1 个订阅者收到了消息　　我们再看看之前的订阅客户端，收到了发布的消息 ? 　　...LuaDemo.java 中有个方法 distLockTest ，有兴趣的可以看看，对理解 Redisson 分布式锁的实现有帮助细节疑问　　给大家留两个问题　　1、客户端未主动取消订阅，而是直接断开连接

1.7K1 0

kafka系列--简介

Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。...（生产者、服务器、消费者） JMS消息传输模型： 1.点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端...这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。 2.发布/订阅模式（一对多，数据生产后，推送给所有订阅者）发布订阅模型则是一个基于推送的消息传送模型。...发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即时当前订阅者不可用，处于离线状态。...3.消息队列最容易理解的方式就是生产者消费者模式，使两个应用解耦。mq等框架就是对这的具体实现。 rpc中主要有两点，一是消息的传输格式(文本或二进制)，二是消息传输方式(http或tcp)。

1381 0

为什么最近每份 Android 简历都说 “熟悉 MQTT 协议”？

一个客户端既可以作为消息发布者，也可以作为消息订阅者； broker (代理)：代理是整个发布 - 订阅模型的核心，也叫服务端。...当 client 发布某个主题的消息时，broker 会将该消息分发给任何已订阅该主题的 client。...发布 - 订阅模式使得消息的发布者和订阅者解耦，主要体现为空间解耦和时间解耦：空间解耦 / 设备解耦：发布者和订阅者通过 broker 进行消息传递，相互之间感知不到对方的存在。...物联网和移动应用场景的特点是硬件性能低下和网络状况不稳定，而 MQTT 协议就是专门针对这种环境设计的，主要在四个方面有优势： 1、架构设计： MQTT 协议采用发布 - 订阅模型，使得消息发布者和消息订阅者互相解耦...4.4 RETAIN 保留消息当 client 发布某个主题的消息时，broker 会将该消息分发给任何已订阅该主题的 client，随后这条消息会从 broker 上删除。

4.1K4 0

【小家Spring】从Spring中的(ApplicationEvent)事件驱动机制出发，聊聊【观察者模式】【监听者模式】【发布订阅模式】【消息队列MQ】【EventSourcing】...

前言说到事件驱动，我心里一直就有一个不解的疑问：它和我们老生长谈的一些概念比如：【观察者模式】【发布订阅模式】【消息队列MQ】【消息驱动】【EventSourcing】等等是一回事吗？...(ApplicationContext接口继承了该接口，担当着事件发布者的角色)。...发布订阅模式：很多人认为等同于观察者模式。但我的理解是两者唯一区别，是发布订阅模式需要有一个调度中心，而观察者模式不需要（观察者的列表可以直接由被观察者维护）。...但它俩混用没问题，一般都不会在表达上有歧义消息队列MQ：中间件级别的消息队列（ActiveMQ,RabbitMQ），可以认为是发布订阅模式的一个具体体现事件驱动->发布订阅->MQ，从抽象到具体。...这类模式的优缺点有点：支持简单的广播通信，自动通知所有已经订阅过的对象目标对象与观察者之间的抽象耦合关系能够单独扩展以及重用（保持职责单一，解耦）观察者模式分离了观察者和被观察者二者的责任，这样让类之间各自维护自己的功能

6.8K7 1

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云