首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

一次在Pub Sub推送订阅中可以有多少条未确认消息

Pub Sub(发布-订阅)是一种消息传递模式,用于解耦发布者和订阅者之间的通信。在Pub Sub中,发布者将消息发送到主题(topic),而订阅者则从主题中接收消息。

在Pub Sub推送订阅中,未确认消息是指发布者发送到主题但尚未收到确认的消息。未确认消息的数量取决于多个因素,包括消息发布的速率、主题的订阅者数量、订阅者的处理能力等。

通常情况下,Pub Sub系统会对未确认消息进行缓冲,并根据订阅者的确认情况进行管理。订阅者接收消息后,会发送确认消息给发布者,表示已成功处理该消息。一旦发布者收到确认消息,就会将对应的未确认消息从缓冲区中移除。

对于未确认消息的数量,具体的限制会根据不同的Pub Sub实现和配置而异。某些Pub Sub系统可能会设置最大未确认消息的数量,超过该数量后将不再接收新的消息,直到有确认消息到达或超时。其他系统则可能没有明确的限制,但会根据可用资源和性能自动进行调整。

在腾讯云中,可以使用消息队列 CKafka 作为Pub Sub系统。CKafka是一种高可靠、高吞吐量的消息队列服务,适用于大规模数据流转、流式计算和异步任务处理等场景。您可以根据实际需求选择适当的CKafka实例规格,并通过消息确认机制控制未确认消息的数量。

腾讯云CKafka产品介绍链接地址:https://cloud.tencent.com/product/ckafka

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

云端协议MQTT介绍

一、简述 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的"轻量级"通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。 MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的,这些特点使它适用范围非常广泛。在很多情况下,包括受限的环境中,如:机器与机器(M2M)通信和物联网(IoT)。其在,通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

03

Redis Stream——作为消息队列的典型应用场景

Redis最新的大版本5.0已经RC1了,其中最重要的Feature莫过于 Redis Stream 了,关于Redis Stream的基本使用介绍和设计理念可以看我之前的一篇文章(Redis Stream简介)。 Redis Stream 本质上是在Redis内核上(非Redis Module)实现的一个消息发布订阅功能组件。相比于现有的 PUB/SUB 、 BLOCKED LIST ,其虽然也可以在简单的场景下作为消息队列来使用,但是 Redis Stream 无疑要完善很多。 Redis Stream 提供了消息的持久化和主备复制功能、新的RadixTree数据结构来支持更高效的内存使用和消息读取、甚至是类似于 Kafka 的 Consumer Group 功能。今天我们重点关注怎么在实际业务场景下去使用 Redis Stream 。

02

PHP与redis队列实现电商订单自动确认收货

一、场景 之前做的电商平台,用户在收到货之后,大部分都不会主动的点击确认收货,导致给商家结款的时候,商家各种投诉,于是就根据需求,要做一个订单在发货之后的x天自动确认收货。所谓的订单自动确认收货,就是在在特定的时间,执行一条update语句,改变订单的状态。 二、思路 最笨重的做法,通过linux后台定时任务,查询符合条件的订单,然后update。最理想情况下,如果每分钟都有需要update的订单,这种方式也还行。奈何平台太小,以及卖家发货时间大部分也是密集的,不会分散在24小时的每分钟。那么,定时任务的话,查询过多,不适合。这里可以先把将要自动确认收货的订单信息存储到其他介质上,比如redis,memcache,rabbitmq,然后执行的脚本从前面的介质获取到订单信息来判断,这里可以大大的减少数据库的查询压力。 redis队列的生产者 对此,我们选择每天在凌晨两点的时候,通过linux的定时任务把即将要确认收货的订单信息查询出来,然后存储在redis上,redis上我们选择的队列,队列处理的特点就是先进先出,前面的数据在查询订单时,通过发货时间排序,所以最先出队列的肯定是距离规定的自动收货时间最近的订单。代码如下

03

知乎技术分享:知乎千万级并发的高性能长连接网关技术实践

实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。 每个互联网公司里几乎都有一套长连接系统,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。 业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。 经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。 知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。

02
领券