消息队列教程

假设有一个分布式应用程序，其中请求在到达时进行处理。我们还要考虑这些请求是耗时的任务，它是由用户对应用程序的操作触发的。由于任务需要花费时间，因此最好将这些请求排入队列，我们​​可以按顺序处理它们，并在任务完成后通知用户。这样我们的系统可以松散地耦合在一起，并提供更好的用户体验，因为不会阻塞

在本教程中，我们将学习为物联网应用程序创建数据管道时需要做什么。在此过程中，我们将了解IoT架构的特征，并了解如何利用MQTT Broker，NiFi和InfluxDB等不同工具来为IoT应用程序构建高度可扩展的数据管道。 物联网及其架构

在本教程中，向您展示NATS消息传递与基于REST的微服务的性能。NATS是高性能云本机消息传递服务器。NATS可以帮助现代分布式系统体系结构中的服务发现，负载平衡，微服务间通信等。我们这里的主要目标是提出一个应用程序-具有2种不同的实现方式（REST和NATS）以实现完全相

消息队列基础概念的指南，以及它们如何应用于当今流行的排队系统。在本指南中，我们将讨论： 什么是消息队列及其历史记录。 为什么它们有用，以及在推理时要使用哪些心理模型。 交付保证了排队系统的语义（至少一次，最多一次和完全一次语义）。 排序和FIF

PubSub是用于微服务体系结构中服务到服务通信的异步消息传递模型：一个服务（发布者，而不是将消息发送给特定的收件人），它发布的消息到一个主题/通道，通过有关各个订阅者（Subscribers）接收消息。好处：一对多通讯，发布者可以发布一条消息，其中N个订阅者可以接收

在排队理论使我们能够预测队列长度和等待时间，这是最重要的容量规划。对于架构师来说，这是一个非常方便的工具，因为队列不仅仅是消息传递系

将异步通信用于微服务时，通常使用消息代理。代理确保不同微服务之间的通信可靠且稳定，确保消息在系统内得到管理和监视，并且消息不会丢失。您可以选择一些消息代理，它们的规模和数据功能各不相同。这篇博客文章将比较三种最受欢迎​​的经纪人：

带有RSocket路由的spring-cloud-bus作为传输的示例应用程序。点击标题进入源码： 克隆https://github.com/spenc

本教程演示分散聚集模式( Scatter Gather Pattern)，它是分布式系统体系结构的企业集成模式之一。让我们考虑一个需要完成一组任务以完成业务工作流程的应用程序。如果这些任务彼此不依赖，那么按顺序执行它们就没有意义。我们可以并行执行这些任务。

一个利用zio-streams和Redisson库来使用和产生事件到Redis流的示例应用程序，基于Java 11，使用ZIO-Streams的Redis Stream消费者和生产者实现。点击标题见Github。 ZIO/ZIO Streams库在Scala函数式编程世界中非

Redis pub-sub就像是一个“一劳永逸”的系统，在其中，您产生的所有消息将立即传递给所有使用者，并且数据不会存储在任何地方。关于Redis，您在内存上有限制。同样，生产者和消费者的数量也会影响Redis的性能。另一方面，Kafka是高吞吐量的分布式日志，可以用作队列。它还为通

消息传递模式的严重错误，导致巨大的耦合和极端的意外复杂性：少而巨大的事件多个服务都可以发布相同的事件每个服务都会改变事件的一部分并重新发布众说纷纭：最后一个在基于文档的消息传递中很常见，可以了！实际上，根据问题空

主要的两个图遍历算法： -广度优先搜索（BFS） -深度优先搜索（DFS） 您知道它们本质上是相同的算法吗？主要区别在于：BFS使用队列，而DFS使用堆栈。基础数据结构完全更改遍历顺序。 最初，它们看起来完全不同，因为DFS通常是通过

场景：在与多个支付提供商进行通信的应用程序上工作场景中，每个提供商对我们都有自己的速率限制。我们不想用任何提供商的费率限制，同时也要充分利用我们允许的限制。我们可以承受将付款请求延迟一小段时间的麻烦，因为批量付款是作为异步作业离线处理的。在平均结算日，我们会在很短的时间内执行大量付款

LinkedIn消息平台现在存储了价值17年的消息（使用17年的不同产品功能创建），并且发送的消息数量一直保持不变往上走。最初，这些消息看起来很像电子邮件。现在，他们看起来更像是聊天，带有主题，群组对话，表情符号，没有主题行。支持该消息传递系统的代码已经过更新，变得越来越复杂，但是多

Redis作为开源内存数据存储不仅限于缓存，还是数据库、事件存储、消息代理、内存数据存储、AI功能存储、AI和搜索解决方案，使我们能够构建超低延迟和高吞吐量的实时应用程序。本文总结了Ofer Bengal（Redis Labs联合创始人兼首席执行官）和Yiftach Shoolman