- 综合排序
- 最热优先
- 最新优先
- 来自专栏Flutter入门到实战
消息传输模型的思考
一、消息传输模型 从消息传输模型上，大致可以抽象为以下几种： （1）点对点模型（Point-to-point） 基础模型中，只有一个发送者、一个接收者和一个分布式队列。 在P2P模型中，有几个关键术语：消息队列(Queue)、发送者(Sender)、接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。 接收者在成功接收消息之后需向队列应答成功。 如果你希望发送的每个消息都应该被成功处理的话，那么你需要P2P模型。 （2）生产者消费者模型（Producer–consumer） 在该模型，三个角色一般称为生产者（Producer）、分布式队列（Queue）、消费者（Consumer）。 其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。
1.4K30发布于 2019-07-23 - 来自专栏笔记本
RabbitMQ的消息可靠传输
RabbitMQ的消息可靠传输AMQP协议架构RabbitMQ是基于AMQP协议实现的消息中间件，AMQP有一套自己的架构，RabbitMQ的架构也基于此。如图所示就是AMQP协议的基础架构。 生产者生产者就是我们发送消息的角色，是消息的发送方，负责把需要被处理的消息发送到下游——交换机。 2.Broker接收到消息但还没有及时存储（持久化）就宕机了，消息也丢失了。3.消费者在取消息的过程中，Broker宕机，或者网络断开。 生成发送消息的时候可以把消息的delivery_mod属性设置为2，就可以将消息标记为持久化。队列也可以通过durable属性设置为true，标记为持久化，这样MQ会将队列持久化到磁盘。 注意如果只将队列持久化但是消息没有持久化，那么消息是会丢失的；同时，只将消息持久化，队列没有持久化的话，消息依旧会丢失，因为消息是存储在对应队列中的。
29021编辑于 2025-07-08 - 来自专栏IT当时语_青山师_JAVA技术栈
消息队列如何保证消息可靠性传输
消息队列如何保证消息可靠性传输 随着互联网的发展，消息队列已经成为了系统设计中不可或缺的一部分。它可以实现系统之间的异步通信和解耦，提高整体系统的可靠性和性能。 但是，由于网络的不可靠性和系统崩溃等原因，消息在传输过程中可能会出现丢失和重复等问题。为了解决这些问题，消息队列需要采用一系列机制来保证消息的可靠性传输。 可靠性传输机制 为了保证消息的可靠性传输，常见的机制包括： 持久化存储 在消息发送之前，消息队列需要将消息进行持久化存储，确保消息在遭遇意外情况时也不会丢失。 消息确认机制 在消息发送完成后，发送方需要接收到接收方的确认消息，才能认为消息发送成功。如果发送方没有接收到确认消息，则需要对消息进行重发，以保证消息的可靠传输。 总结 以上就是消息队列如何保证消息可靠性传输的介绍。
90510编辑于 2023-05-05 - 来自专栏向治洪
实时消息传输协议（RTMP）详解
通常情况下，不同类型的消息会被分配不同的优先级，当网络传输能力受限时，优先级用来控制消息在网络底层的排队顺序。 RTMP块流 实时消息传递协议块流(RTMP块流)。 RTMP块流被设计用来传输实时消息协议，它可以使用任何协议来发送消息流。每个消息都包含时间戳和有效类型标识。 当RTMP协议在互联网中传输数据的时候，消息会被拆分成更小的单元，称为消息块（Chunk）。 消息 消息是RTMP协议中基本的数据单元。 消息的报文结构如下图所示。 ? 消息块 在网络上传输数据时，消息需要被拆分成较小的数据块，才适合在相应的网络环境上传输。RTMP协议中规定，消息在网络上传输时被拆分成消息块（Chunk）。 RTMP传输媒体数据的过程中，发送端首先把媒体数据封装成消息，然后把消息分割成消息块，最后将分割后的消息块通过TCP协议发送出去。
13.5K52发布于 2018-02-06 - 来自专栏JavaEdge
消息队列面试解析 - 传输协议
比如： 03下雨天03留客天02天留03我不留 这里固定使用2位数字来存放长度，每句话最长可支持到99个字。 接收后的处理就比较简单，先读取2位数字03，知道接下来3个字是第一句话，那我们接下来就等着这3个字都收到了，就可以作为第一句话，接下来再按照这个方法来读第二句话、第三句话。 2 双工收发 单工通信就是，任何一个时刻，数据只能单向传输，一个人说的时候，另外一个人只能听。 双工通信，就是说不管是客户端还是服务端建立好链接之后，双方都可以基于该socket进行收发消息就好了，而不是说服务器只能accept到message之后再做一些处理。 那接到消息的一方，该如何分辨序列号的长度大小，做到区分序列号和内容前的数据长度信息？ 开头是数据长度，序号也是数据的一部分，所以应该在长度之后。
59010发布于 2021-02-22 - 来自专栏网络
消息传输的设计方式（上）
Apache Pulsar Pulsar是分布式订阅发布消息传输系统，最早有由Yahoo公司开发的，并在2016年正式开源。 Pulsar提供了灵活消息传输、多租户、跨地理位置数据复制等特性。 Pulsar的创始人Joe和Matteo等人认为需求是Pulsar项目启动的原因，如果应用程序提供实时服务，需要保证平均5ms以内的发布延迟，99%的请求不会超过15ms的延迟，同时满足分类、强持久性以及传输保证等特征的消息传输系统 命名空间是Pulsar集群的最基本管理单元，在命名空间级别，你可以设置权限、调优复制策略、管理跨集群的消息数据复制、控制消息过期，以及其他关键操作。同一个命名空间里的主题共享相同的配置。 Apache Pulsar Pulsar是分布式订阅发布消息传输系统，最早有由Yahoo公司开发的，并在2016年正式开源。 Pulsar提供了灵活消息传输、多租户、跨地理位置数据复制等特性。 Pulsar的创始人Joe和Matteo等人认为需求是Pulsar项目启动的原因，如果应用程序提供实时服务，需要保证平均5ms以内的发布延迟，99%的请求不会超过15ms的延迟，同时满足分类、强持久性以及传输保证等特征的消息传输系统
1.2K80发布于 2018-01-09 - 来自专栏码出code
SpringBoot 整合 RabbitMQ 实现消息可靠传输
消息的可靠传输是面试必问的问题之一，保证消息的可靠传输主要在生产端开启 comfirm 模式，RabbitMQ 开启持久化，消费端关闭自动 ack 模式。 消息丢失分析 一条消息的从生产到消费，消息丢失可能发生在以下几个阶段： 生产端丢失：生产者无法传输到 RabbitMQ 存储端丢失：RabbitMQ 存储自身挂了 消费端丢失：存储由于网络问题，无法发送到消费端 ，或者消费挂了，无法发送正常消费 RabbitMQ 从生产端、储存端、消费端都对可靠性传输做很好的支持。 生产阶段 生产阶段通过请求确认机制，来确保消息的可靠传输。 交换机正确，发送不存在的队列： 交换机接收到消息，返回成功通知，控制台输出： 【correlationData】:CorrelationData [id=7d468b47-b422-4523-b2a2
57230编辑于 2023-02-26 - 来自专栏架构师
图解：消息传输的架构模式
从概念上讲，一条消息是一个发送方与一个或多个接收方之间的一次信息交换。自从大型机问世以来，消息交换一直是计算机编程和架构设计的重要组成部分。 多年来，消息传输的实践已经发展成多种消息传输模式。 1消息交换架构 本节描述与在发送方和接收方之间传输消息的机制相关的消息传输模式。 然后，当一条消息发送到该主题时，所有订阅者都将收到发送到该主题的消息的副本。该消息被“分发出去”。（请参见下面的图 2） ? 双向流模式在服务器和接收方之间在两个方向上连续不断地流转数据 双向流传输的一个示例是 gRPC。gRPC 在 HTTP/2 下运行，它允许发送方建立与接收方的恒定连接。 2路由 本节列出的消息传输模式描述了在发送方和接收方之间路由消息的各种方法。发布 - 订阅、扇出和流模式专注于数据传输的架构，而单播、广播、多播和任播模式则专注于路由。
73520发布于 2021-06-10 - 来自专栏架构之家
图解：消息传输的架构模式
从概念上讲，一条消息是一个发送方与一个或多个接收方之间的一次信息交换。自从大型机问世以来，消息交换一直是计算机编程和架构设计的重要组成部分。 多年来，消息传输的实践已经发展成多种消息传输模式。 消息交换架构 本节描述与在发送方和接收方之间传输消息的机制相关的消息传输模式。 发布-订阅 发布-订阅（Pub-Sub）模式指的是发布者将消息发送到消息代理（broker）上的主题（topic）。 （请参见下面的图 2） 扇出模式将向所有感兴趣的订阅者发送消息的副本 Twitter 是扇出模式的一个很好的例子。某人发送一条推文后，推文会发送给所有粉丝。 双向流模式在服务器和接收方之间在两个方向上连续不断地流转数据 双向流传输的一个示例是 gRPC。gRPC 在 HTTP/2 下运行，它允许发送方建立与接收方的恒定连接。 用通用名称封装消息传输模式的好处在于，它允许架构师和开发人员以相同的方式讨论同一件事。对消息传输模式使用常规名称可以节省时间。
80720编辑于 2022-07-12 - 来自专栏JavaEdge
消息的可靠性传输，如何处理消息丢失问题？
若RabbitMQ未能处理该消息，就会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。可结合该机制，自己在内存里维护每个消息id的状态，若超过一定时间还没接收到该消息的回调，你就能重发。 设置持久化 创建queue时，将其设置为持久化，保证RabbitMQ持久化queue的元数据，但不会持久化queue里的数据 发送消息时，将消息的deliveryMode设为2：将消息设置为持久化的，此时 2 Kafka 消费端丢数据 唯一可能导致Con丢数据case：消费到了该消息，然后Con自动提交了offset，让kafka以为你已消费完该消息，然而其实你刚准备处理这消息，你还没处理完，你就挂了， 一般要求起码设置如下参数： 给topic设置replication.factor参数：必须大于1，要求每个partition必须有至少2个副本 在kafka Broker设置min.insync.replicas 在 RocketMQ 中，事务消息可以保证消息零丢失。
1.5K20编辑于 2022-11-30 - 来自专栏码农编程进阶笔记
基于极光推送实现消息传输(PHP版)
一、如何用php实现APP消息推送 现在有很多的消息推送厂商，比如阿里云的消息推送，极光推送，融云的消息推送。 他们的原理都是把sdk内置在app里面，达到消息推送的目的，通过一张图来了解一下，看不懂的也不要紧，理解大概的过程就行。 二、准备接入 1.进入极光官网，注册一个app应用 2.集成厂商推送服务（！！！非常重要，不然推送不了——） 3.中途还要验证企业用户，集成完把sdk发给app开发人员。
1.3K30编辑于 2022-04-08 - 来自专栏Java程序猿部落
如何保证消息的可靠性传输？
面试题 如何保证消息的可靠性传输？或者说，如何处理消息丢失的问题？ 如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中绝对不会把计费消息给弄丢。 中，RabbitMQ 会给你回传一个 ack 消息，告诉你说这个消息 ok 了。 第二个是发送消息的时候将消息的 deliveryMode 设置为 2 就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。 所以此时一般是要求起码设置如下 4 个参数： 给 topic 设置 replication.factor 参数：这个值必须大于 1，要求每个 partition 必须有至少 2 个副本。
1.3K10发布于 2019-05-31 - 来自专栏RTSP/RTMP直播相关
GBT 28181-2016多响应消息传输探究
我们在实现Android平台GB28181设备接入模块的时候，有遇到发送多条记录的情况，本文主要探讨下GB28181多响应传输。 为了保证多条响应、通知消息传输的稳定可靠，多条响应、通知消息发送时宜采用串行发送方式，记录发送方需收到上一条SIP Message消息的SIP响应后再进行后续发送处理。 待发送记录条数达到百条级别时,为缩短传输时间宜在每条响应消息中携带多条记录，每条响应消息携带记录上限为10000条。 目录查询应答命令应支持多响应消息传输的要求。 源设备包括SIP客户端、网关或联网系统,目标设备包括SIP设备、网关或联网系统。 设备视音频文件检索文件检索主要用区域、设备、录像时间段、录像地点、录像内容为条件进行查询,用 Message消息发送检索请求和返回查询结果,传送结果的 Message消息可以发送多条,应支持多响应消息传输的要求
58500编辑于 2022-10-26 - 来自专栏码出code
如何保证消息队列的可靠性传输？
消息丢失分成三种情况，可能出现生产者、RabbitMQ、消费者。 生产者丢失数据 首先要确保写入 RabbitMQ 的消息别丢，消息队列通过请求确认机制，保证消息的可靠传输。 生产开启 comfirm 模式，在生产者开启 comfirm 模式之后，每次发送消息都会分配一个唯一的id。 如果写入了 RabbitMQ 中，RabbitMQ 会回传一个 ack 消息 如果没能写入 RabbitMQ，会回调一个 nack 接口， 可以重新发送消息 一般在生产者这块避免数据丢失，都是用 confirm 还有一种少见的情况，就是RabbitMQ还没将消息持久化，自己就挂了。这种情况需要生产者那边的确认机制结合起来。只有消息被持久化到磁盘以后，才会回传 ack 消息。 每次在消费端处理后，再在程序里做 ack 确认，这样的话，如果没有处理完，就没有 ack 确认，那 RabbitMQ 就认为你还没有处理完，这个时候 RabbitMQ 会重新发送消息给消费者。
49610编辑于 2023-02-25 - 来自专栏用户2442861的专栏
实时消息传输协议 RTMP(Real Time Messaging Protocol)
以下是维基百科原文： 实时消息传输协议(RTMP)最初是由 Macromedia 为互联网上 Flash player 和服务器之间传输音频、视频以及数据流而开发的一个私有协议。 为了能够顺利地传输流，并且传递尽可能多的信息，RTMP 对流进行分段，客户端和服务器可以对分段长度进行协商，尽管有时分段长度是不变的：对于音频数据默认分段长度是 64 字节，视频数据和大部分其他数据类型默认分段长度是为 值为 2 用于底层的消息，例如 Ping 和设置客户端带宽。 接下来的 RTMP 报头的字节(包含以上数据包例子中的值)详解如下： 字节 #1 (0x03) = 块头类型。 #2-3 - 第二个参数 (对于特定的 Ping 类型有意义)。 #4-5 - 第三个参数 (一样)。 消息体的前两个字节定义了 Ping 的类型，有六种可能取到的值。 C2 和 S2 分别是 S1 和 C1 的回声，接收到它们之后，握手才被认为结束。 ? 连接 这一点上，客户端和服务器会通过交互 AMF 编码的消息进行协商连接。
3.1K10发布于 2018-09-20 - 来自专栏大内老A
WCF如何克服HTTP传输协议的局限提供对不同消息传输模式的实现
消息会被WCF的信道层发送到传输层，并通过相应的传输协议发送到目的地。对于TCP协议来说，其本身就能提供一个双工通道，所以能够对以上三种MEP原生的支持。 One-Way模式基于从一个源到一个或者多个目的地的单向消息传输。如右图所示，在One-Way模式下，消息的发送方将消息发送到接收方，并不希望收到对象的回复。 现在，客户端通过创建的服务代理，简单地调用Add（1,2)这么一个简单的服务操作。 主题发布的时候，发布方提取当前主题的所有订阅方，对它们进行消息广播。 ? 消息的交换依赖于网络传递，不同的网络传输协议对双工通信具有不同的支持方式。 从消息交换的角度讲，客户端调用服务端和服务端对客户端进行回调，本质上是一样的。所以，从HTTP传输层看，真正的消息交换方式如左图所示。
1.4K70发布于 2018-01-16 - 来自专栏明丰随笔
浅谈消息队列 2
目前使用较多的消息队列有 ActiveMQ， RabbitMQ， Kafka， RocketMQ， 我们后面会一一对比这些消息队列。 JMS（JAVA Message Service,java消息服务） JMS的客户端之间可以通过JMS服务进行异步的消息传输。 API是一个消息服务的标准或者说是规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 2. JMS 支持TextMessage、MapMessage 等复杂的消息类型；而 AMQP 仅支持 byte[] 消息类型（复杂的类型可序列化后发送）。 3. 2. RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。
62940发布于 2019-08-09 - 来自专栏EMQ 物联网
MQTT QoS 设计：车联网平台消息传输质量保障
接下来，我们就需要考虑如何将消息数据进行高质量的安全传输。在本篇文章中，我们将借助 MQTT 协议的 QoS 特性，介绍车联网场景中的 MQTT 消息 QoS 设计，保障数据传输质量。 QoS 保证了在不同的网络环境下消息传递的可靠性，可作为车联网场景中保障消息可靠性传输的首要实现技术。 以下情况下可以选择 QoS 2 对于不能忍受消息丢失，且不希望收到重复的消息，数据完整性与及时性要求较高的场景，可以选择 QoS 2。 QoS 2 主要运用于对数据完整性与及时性要求较高的银行、消防、航空等行业，有些主机厂的行车告警和车辆充电桩计费费单消息会选择采用 QoS 2。 例如：A 发送的消息 QoS 为 2，B 订阅的消息 QoS 为1，则最终接收到消息的 QoS 为 1。
1.3K20编辑于 2022-07-04 - 来自专栏软件工程
如何保证消息的可靠性传输（如何处理消息丢失的问题）
channel.txCommit(); } catch (Exception e) { e.printStackTrace(); channel.txRollback(); } 方法2 会给你回传一个ack消息，告诉你说这个消息ok了。 而且由于可能存在网络波动，消息没发出去情况，因此你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。 cnofirm机制最大的不同在于 : 事务机制是同步的，你提交一个事务之后会阻塞在那儿 confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了 deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。
99620编辑于 2022-05-13 - 来自专栏技术之路
剖析nsq消息队列(三) 消息传输的可靠性和持久化diskqueue
上一篇主要说了一下nsq是如何保证消息被消费端成功消费，大概提了一下消息的持久化,--mem-queue-size 设置为 0，所有的消息将会存储到磁盘。 nsq自己实现了一个先进先出的消息文件队列go-diskqueue是把消息保存到本地文件内，很值得分析一下他的实现过程。 xxxx.diskqueue.meta.dat 元数据保存了未读消息的长度，读取和存入数据的编号和读取位置 xxxx.diskqueue.编号.dat 消息保存的文件，每一个消息的存储：4Byte消息的长度 +消息 ? ，4个bit的大小，然后读取具体的消息。
1.4K10发布于 2019-11-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号