现如今，消息中间件已经在很多公司的业务中被广泛使用：业务解耦，消峰填谷，对接大数据，流式计算等等各种玩法层出不穷。伴随着消息中间件的使用，你一定还听过 "消息队列"，“pub-sub”这些名词，我们今天就来聊一下这些消息中间件提供给业务的可使用的 "Style"。
Wormhole是Facebook内部使用的一个Pub-Sub系统，目前还没有开源。 在网上搜索论文相关内容的时候，发现几个网站，首先是该篇论文有个视频： https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/sharma 由此知道了OSDI(Operating Systems Design and Implementation )大会，并且搜索到一个最佳论文的网址： https://www.usenix.org/conferences/best-papers 以后可以关注下。 第二个发现的好的内容是： https://blog.acolyer.org/2015/05/14/wormhole-reliable-pub-sub-to-support-geo-replicated-internet-services/ 该博客会每天推送一篇论文，特别棒。 第3个是发现的一个学校课程：https://courses.engr.illinois.edu/cs525/sched.htm 里面有介绍该篇论文的ppt，其他内容也特别棒，可以关注下。
观察者模式和发布订阅模式有什么区别？大多数的回答都是：Publishers + Subscribers = Observer Pattern，24种基本的设计模式并没有发布-订阅模式，发布订阅模式属于并发型模式；像典型的Mq；这两种相似单并不可以划等号。
Pub-sub架构（发布/订阅），异步的服务间通信方式，适用于无服务器和微服务。发布到主题的任何消息都会立即被主题的所有订阅者接收。
"Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API."
从概念上讲，一条消息是一个发送方与一个或多个接收方之间的一次信息交换。自从大型机问世以来，消息交换一直是计算机编程和架构设计的重要组成部分。
“Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API.”
本文介绍在 Redis、Apache Kafka、RabbitMQ、ZeroMQ 和 IBM MQ 等技术中使用的消息交换架构和路由方法的基本模式。另外介绍如何使用这些模式简化架构师和开发人员之间的互动。
以上代码分为两个文件，一个是Server.cpp，另一个是Client.cpp。Server.cpp创建一个REP类型的socket，并绑定到"tcp://*:5555"地址上。在服务器的无限循环中，它接收来自客户端的请求消息，然后发送一个回复消息。
Dapr 是一个可移植的、事件驱动的运行时，它使任何开发人员能够轻松构建出弹性的、无状态和有状态的应用程序，并可运行在云平台或边缘计算中，它同时也支持多种编程语言和开发框架。
组件间的关系 父子组件 兄弟组件（非嵌套组件） 祖孙组件（跨级组件） 通信方式 props：children props、render props 消息订阅-发布：pub-sub 集中式管理：redux conText：生产者-消费者模式 搭配方式 父子组件：props 兄弟组件：消息订阅-发布，集中式管理 祖孙组件：消息订阅-发布，集中式管理，conText（封装插件使用的多）
Apache Kafka是基于发布/订阅的容错消息系统，由Scala和Java编写，是一个分布式消息队列，具有高性能、持久化、多副本备份、横向扩展能力。
这篇的内容是关于分布式消息队列的，无论是在实时系统，还是在非实时系统中，它都有广泛的应用。作为一个消息队列，基本的功能需求相对好描述，简单说有两条：
问题导读 1.什么是Pulsar？ 2.Pulsar都有哪些概念？ 3.Pulsar有什么特点？ 4.Flink未来如何与Pulsar整合？ Apache Flink和Apache Pulsar的开源数据技术框架可以以不同的方式集成，以提供大规模的弹性数据处理。 在这篇文章中，我将简要介绍Pulsar及其与其他消息传递系统的差异化元素，并描述Pulsar和Flink可以协同工作的方式，为大规模弹性数据处理提供无缝的开发人员体验。 Pulsar简介 Apache Pulsar是一个开源的分布式pub-sub消息系统，由Apache Software Foundation管理。 Pulsar是一种用于服务器到服务器消息传递的多租户，高性能解决方案，包括多个功能，例如Pulsar实例中对多个集群的本地支持，跨集群的消息的无缝geo-replication，非常低的发布和端到端 - 延迟，超过一百万个主题的无缝可扩展性，以及由Apache BookKeeper等提供的持久消息存储保证消息传递。现在让我们讨论Pulsar和其它pub-sub消息传递框架之间的主要区别： 第一个差异化因素源于这样一个事实：虽然Pulsar提供了灵活的pub-sub消息传递系统，但它也有持久的日志存储支持 - 因此在一个框架下结合了消息传递和存储。由于采用了分层架构，Pulsar提供即时故障恢复，独立可扩展性和无平衡的集群扩展。 Pulsar的架构遵循与其他pub-sub系统类似的模式，因为框架在主题中被组织为主要数据实体，生产者向主体发送数据，消费者从主题（topic）接收数据，如下图所示。
发布订阅是一种设计模式，它允许应用程序组件之间进行松散耦合。 其实订阅发布设计中主要是发布者生成事件通道，用于在不了解任何订阅者存在的情况下通知订阅者。
最初，BIGO 的消息流平台主要采用开源 Kafka 作为数据支撑。随着数据规模日益增长，产品不断迭代，BIGO 消息流平台承载的数据规模出现了成倍增长，下游的在线模型训练、在线推荐、实时数据分析、实时数仓等业务对消息流平台的实时性和稳定性提出了更高的要求。开源的 Kafka 集群难以支撑海量数据处理场景，我们需要投入更多的人力去维护多个 Kafka 集群，这样成本会越来越高，主要体现在以下几个方面：
作者 | 陈航 BIGO 于 2014 年成立，是一家高速发展的科技公司。基于强大的音视频处理技术、全球音视频实时传输技术、人工智能技术、CDN 技术，BIGO 推出了一系列音视频类社交及内容产品，包括 Bigo Live（直播）和 Likee（短视频）等，在全球已拥有近 1 亿用户，产品及服务已覆盖超过 150 个国家和地区。 1挑战 最初，BIGO 的消息流平台主要采用开源 Kafka 作为数据支撑。随着数据规模日益增长，产品不断迭代，BIGO 消息流平台承载的数据规模出现了成倍增长，下游的在线模型训练
快手前天发布了《看见》一时间好评如潮，盖过了之前的《后浪》。现如今搞内容创作都要开始玩价值观导向了。不过互联网真是一个神奇的东西，我们足不出户就可以看到你想看的东西。不管是时下火热的抖音、快手，还是微信公众号、知乎。你只需要关注订阅你喜欢的领域，你就可以获取你想要的内容，甚至和创作者进行互动。创作者只需要创作的内容发布到对应的平台上，用户只需要在对应的平台上订阅自己喜欢的领域或者作者就可以了。用户和创作者并不认识，但是他们却可以“看见”。从编程范式上来说这就是发布-订阅。
在软件架构中，发布订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者）。而是将发布的消息分为不同的类别，无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者（如果有的话）存在。 举个报纸的例子： 还是得说一下报纸，有人说报纸不就是观察者模式，那得有多少观察者和主题？一张报纸那么多板块，订报纸的人那么多，难道要一个人一个人的通知，显然不现实。如果在记者（编辑）和读者之间加了一个载体报纸，那么这还是观察者模式吗？ 无数的编辑将新闻发到报设，报社在将信息整合到报纸同意发送到读者手中，显然这不是观察者模式，观察者模式中，观察者和主题有着很强的耦合性，而在这里显然记者不认识读者，读者也不能通过报纸直接和编辑通信，这就是发布者订阅者模式，简单来说和发布者的区别就是多了一家报社。兴许我这朴实的例子并不能让你看明白，我们看一下国外的大佬怎么说？
消息队列是当代分布式系统架构中非常重要的一部分，在应用解耦、流量削峰、异步通信等方面有非常多的应用场景。目前最为我们所熟知的消息队列有：ActiveMQ、Kafka、RabbitMQ、Pulsar和RocketMQ，他们都有哪些优势和劣势， 我们应该如何选择呢？相信这是摆在很多开发者面前的问题。
发送者将消息发送给消息队列之后，不需要同步等待消息接收者处理完毕，而是立即返回进行其它操作。消息接收者从消息队列中订阅消息之后异步处理。
WebSocket协议是应用程序处理实时消息的方法之一。最常见的替代方案是长轮询(long polling)和服务器推送事件(server-sent events)。这些解决方案中的每个都有其优缺点。在本文中，我将向您展示如何使用 SpringBoot实现 WebSocket。我将介绍服务器端和客户端设置，使用 WebSocket协议之上的 STOMP进行相互通信。
前面我们了解了如果在 Dapr 下面进行服务调用，以及最简单的状态管理，本节我们来了解如何启用 Dapr 的发布/订阅模式，发布者将生成特定主题的消息，而订阅者将监听特定主题的信息。
MQTT （Message Queuing Telemetry Transport，消息队列遥测传输） 是一种标准化的发布/订阅消息传输协议，设计于1999年，最初是为了在卫星之类的物体上使用。它是一个非常轻量级的协议，由于对带宽需求很低，从而成为了 M2M 通信或物联网应用的理想选择，现在已经成为这类场景最常见的协议之一。 本文会对该协议及一些使用范例做以简介，虽然没打算写成 MQTT 的综合性参考指南，但会提供足够的信息，让开发人员了解到如何安装运行这一协议。如果想要更深入地了解，可以参考 HiveMQ
PS：另外就是——根据基准测试，Hazelcast在获取数据方面比Redis快56％，在设置数据方面比Redis快44％。
今天，我们开始了我们的新旅程，这就是Apache Kafka教程。在这个Kafka教程中，我们将看到什么是Kafka，Apache Kafka的历史，为什么是Kafka。此外，我们还将学习Kafka架构、Kafka的组件和Kafka分区。此外，我们还将讨论Kafka的各种比较和Kafka的使用案例。除此之外，我们将在这个Kafka教程中看到各种术语，如Kafka Broker、Kafka Cluster、Kafka Consumer、Kafka Topics等。
NATS是一个开源、轻量级、高性能的分布式消息中间件，实现了高可伸缩性和优雅的Publish/Subscribe模型，使用Golang语言开发。
对微服务使用异步通信时，通常使用消息代理。代理确保不同微服务之间的通信可靠且稳定，消息在系统内得到管理和监控，并且消息不会丢失。您可以从几个消息代理中进行选择，它们的规模和数据功能各不相同。这篇博文将比较三种最受欢迎的代理：RabbitMQ、Kafka 和 Redis。 微服务通信：同步和异步 微服务之间有两种常见的通信方式：同步和异步。在同步通信中，调用者在发送下一条消息之前等待响应，它作为 HTTP 之上的 REST 协议运行。相反，在异步通信中，消息是在不等待响应的情况下发送的。这适用于分布式系
该文介绍了如何使用Kafka进行分布式消息处理系统。文章首先介绍了Kafka的基本概念，然后详细描述了Kafka的架构和组件。接着，文章深入探讨了Kafka的复制和分布式协调功能，以及如何使用Kafka进行消息处理。最后，文章介绍了Kafka的性能优化和常见问题解决方案。
image.png 适应场景 异步处理，应用解耦，流量削锋和消息通讯 对比 feature scenario Kafka RabbitMQ 备注 PUB-SUB 发布订阅模型 √ √ 推拉消费 Consumer消费消息的动作方式。 pull push/pull push更关注实时性。pull更关注消费者消费能力。 延迟消费 Producer产生一条消息后，并不希望立刻被消费掉。 X √ 高阶需求。 consumer group 同一条Message能同时被多个消费组消费，但同一group中，一条Messa
在 Database Mesh 中，Pisanix 是一套以数据库为中心的治理框架，为用户提供了诸多治理能力，例如：数据库流量治理，SQL 防火墙，负载均衡和审计等。在 Pisanix 中，Pisa-Proxy 是作为整个 Database Mesh 实现中数据平面的核心组件。Pisa-Proxy 服务本身需要具备 MySQL 协议感知，理解 SQL 语句，能对后端代理的数据库做一些特定的策略，SQL 并发控制和断路等功能。在这诸多特性当中，能够理解 MySQL 协议就尤为重要，本篇将主要介绍 MySQL 协议和在 Pisa-Proxy 中 MySQL 协议的 Rust 实现。
现在有 2 个服务，Service A 和 Service B，通过 REST 接口通信；Service A 在某个业务场景下调用 Service B 的接口完成一个计算密集型任务，假设接口为 http://service_b/api/v1/domain；该任务运行时间很长，但 Service A 不想一直阻塞在接口调用上。为了满足 Service A 的要求，通常有 2 种方案：
Hazelcast 是一个平台性的分布式内存网格计算框架引擎，可以实现基于分布式内存计算的诸多场景的应用框架 , 它作为一个开源可内嵌式内存网格计算框架，通过简单的配置, 就可以轻松的让你的应用拥有弹性可扩展的分布式内存计算能力，可以带你瞬间进入内存计算的时代。
本系列主要目的在于记录腾讯云物联网设备端的学习笔记，并且对设备端SDK进行补充说明。
SAP Subscription Billing是SAP推出的用于订阅关系（Subscription）管理的一款SaaS产品。通常来说，任意一个标准产品都不可能满足所有客户的实际需求；因此，随着客户越来越多，产品的可扩展性显着尤其重要。这篇文章简单介绍一下Subscription Billing的可扩展性功能。
近年来，随着微服务架构的流行，分布式消息引擎在物联网、分布式事务、实时计算和大规模缓存同步等场景中的应用日益增多。本文将分享微众银行基于RocketMQ构建消息服务平台的实践，并通过添加诸多高级特性来解决消息收发过程中遇到的各种问题，通过此文，您将了解到：
钟华，腾讯云高级工程师，Istio project member、contributor，专注于容器和服务网格，在容器化和服务网格生产落地方面具有丰富经验，目前负责 Tencent Cloud Mesh 研发工作。 引言 Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到今年2月正式发布 V1.0 版本。在不到一年半的时间内，github star 数达到了 1.2 万，超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。 Dapr 这个词是是
这是一头漂亮的"冰羚"，它是一种用于汽车软件中的 ICP 通信中间件，由 Eclipse 基金会发布和维护。
基本概念 Basic Conception Session 会话 定义 定义：某个客户端（由ClientID作为标识）和某个服务器之间的逻辑层面的通信 生命周期（存在时间）：会话 >= 网络连接 ClientID 客户端唯一标识，服务端用于关联一个Session 只能包含这些 大写字母，小写字母 和 数字（0-9a-zA-Z），23个字符以内 如果 ClientID 在多次 TCP连接中保持一致，客户端和服务器端会保留会话信息（Session） 同一时间内 Server 和同一个 ClientID 只能保持一个 TCP 连接，再次连接会踢掉前一个 CleanSession 标记 在Connect时，由客户端设置 0 —— 开启会话重用机制。网络断开重连后，恢复之前的Session信息。需要客户端和服务器有相关Session持久化机制。 1 —— 关闭会话重用机制。每次Connect都是一个新Session，会话仅持续和网络连接同样长的时间。 客户端 Session 已经发送给服务端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 已从服务端接收，但是还没有完成确认的 QoS 2 级别的消息 服务器端 Session 会话是否存在，即使会话状态的其它部分都是空 (SessionFlag) 客户端的订阅信息 (ClientSubcription) 已经发送给客户端，但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 即将传输给客户端的 QoS 1 和 QoS 2 级别的消息 已从客户端接收，但是还没有完成确认的 QoS 2 级别的消息 （可选）准备发送给客户端的 QoS 0 级别的消息 长连接维护与管理 Keep Alive 心跳 目的是保持长连接的可靠性，以及双方对彼此是否在线的确认。 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文，它必须断开客户端的网络连接 Keep Alive 的值由具体应用指定，一般是几分钟。允许的最大值是 18 小时 12 分 15 秒 Will 遗嘱 遗嘱消息（Will Message）存储在服务端，当网络连接关闭时，服务端必须发布这个遗嘱消息，所以被形象地称之为遗嘱，可用于通知异常断线。 客户端发送 DISCONNECT 关闭链接，遗嘱失效并删除 遗嘱消息发布的条件，包括： 服务端检测到了一个 I/O 错误或者网络故障 客户端在保持连接（Keep Alive）的时间内未能通讯 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接 由于协议错误服务端关闭了网络连接 相关设置项，需要在Connect时，由客户端指定 Will Flag —— 遗嘱的总开关 0 -- 关闭遗嘱功能，Will QoS 和 Will Retain 必须为 0 1 -- 开启遗嘱功能，需要设置 Will Retain 和 Will QoS Will QoS —— 遗嘱消息 QoS 可取值 0、1、2，含义与消息QoS相同 Will Retain —— 遗嘱是否保留 0 -- 遗嘱消息不保留，后面再订阅不会收到消息 1 -- 遗嘱消息保留，持久存储 Will Topic —— 遗嘱话题 Will Payload —— 遗嘱消息内容 消息基本概念 报文标识 Packet Identifier 存在报文的可变报头部分，非零两个字节整数 (0-65535] 一个流程中重复：这些报文包含 PacketID，而且在一次通信流程内保持一致： PUBLISH(QoS>0 时)，PUBACK，PUBREC，PUBREL，PUBCOMP SUBSCRIBE, SUBACK UNSUBSCIBE，UNSUBACK 新的不重复：客户端每次发送一个新的这些类型的报文时都必须分配一个当前 未使用的PacketID 当客户端处理完这个报文对应的确认后，这个报文标识符就释放可重用。 独立维护：客户端和服务端彼此独立地分配报文标识符。因此，客户端服务端组合使用相同的报文标识符可以实
cpp订阅 create_subscription<std_msgs::msg::String>("chatter", rclcpp::SensorDataQoS(), callback);
设计模式的定义是：在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。通俗一点说，设计模式是在某种场合下对某个问题的一种解决方案。如果再通俗一点说，设计模式就是给面向对象软件开发中的一些好的设计取个名字。
我们公司业务系统一开始体量较小，很多组件都是单机版就足够，后来随着用户量逐渐扩大，我们程序也采用了微服务的设计思想。
官方示例pub和sub使用std_msgs/msg/string.hpp，数据类型std_msgs::msg::String。
消息中间件在现代系统中非常关键,包括阿里云,腾讯云都有直接的消息中间件服务,也就是你不用自己搭建服务器,直接使用它提供的服务就可以了.那么我们今天就从零开始一步一步搭建一个极简消息中间件. 当然我们不可能做到像阿里云的RocketMQ那么复杂,但是最核心功能还是要保证的.
今天我们来聊聊 Kafka ，主要是带你重新认识一下 Kafka，聊一下 Kafka 中比较重要的概念和问题。在后面的文章中我会介绍：
主要的目标是测试MQ队列的性能表现，以确定其在各种不同的网络和硬件环境下的性能表现，以及其在负载增加时的响应速度和稳定性。
但是，可能在平常，写业务代码，真实用到这两样设计思想的并不多，只好在做技术总结的时候复盘一下，温故再温故啦。（也有一种可能是：或许是运用还不是很熟，在有些场景，可以用到，但会忽视掉）
Pub/Sub（发布/订阅）是一种消息传递模式，它允许一个或多个订阅者监听一个特定的主题（频道），当有新的消息发布到该主题时，所有订阅者都会收到通知。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
