消息队列教程

在Kafkaesque，我们的使命是使开发人员能够使用与云无关的高性能消息传递技术，使其易于所有人使用，从而使他们能够构建云原生的分布式应用程序。开发人员希望编写分布式应用程序或微服务，但不希望管理复杂的消息基础结构或被某个特定的云供应商所困扰。他们需要一个可行的解决方案。当您着手构

分布式系统中的状态复制协调非常困难。在一系列联网过程中如何共享状态数据信息并彼此保持同步？最近，RabbitMQ团队发布了一种新型的队列，该队列使用

目的如果您的可访问性资源有限（例如：音频或数据库），则事件队列是一种很好的模式，但是您需要处理所有想要使用它的请求。它将所有请求放入队列并异步处理它们。当事件是队列中的下一个事件时为其提供资源，同时将其从队列中移除。

如果有分布式事务协议，那么每个软件工程师都知道它：“两阶段提交”，也称为2PC。尽管使用了几十年，但是由于缺乏云环境的支持，它却一直在稳步下降。过去在相当长的一段时间里，它是构建企业分布式系统的实际标准。也就是说，随着云成为默认的部署模型，设计人员需要学习如何在没有云的情况下构建可靠

让我们跳过微服务的推销 - 你已经知道它们是什么以及为什么它们有意义。事实上，近年来几乎没有什么话题能够获得如此多的报道，因为将一件大东西分解成许多小东西可以让它更容易处理。麻烦的是：一旦我们打碎了我们的单体巨石，我们如何将它重新组合成一个仍然有意义的更大的系统？尽管Istio，Ko

Poison Pill是已知的预定义的数据项，它为分布式消费使用过程提供优雅的关闭。

INDU Alagarsamy最近在  QCon大会纽约2019大会谈到如何使用定义良好的限界上下文和事件相结合开发微服务，从而能灵活地适应业务的变化。当你开始在干

大多数应用程序至少具有一个批处理任务，在后台执行特定的逻辑。编写批处理作业并不复杂，但是您需要了解一些基本规则，这里将列举一些我发现最重要的规则。从输入类型的角度来看，处理项目可以通过轮询数据库来实现，也可以将数据通过队列推送到系统中来实现。下面显示了典型批处理系统的三个主要组件：<

目的生产者—消费者设计模式是一种经典的并发模式，它通过将工作识别与工作执行分离来减少生产者和消费者之间的耦合。

vel0city：我已经在相当小的VM上运行RabbitMQ很长时间了。RabbitMQ不需要每条消息大量的资源，即使使用非常小的VM（512MB RAM，单个CPU），我也看到它每秒处理数千条消息的峰值而不会出现问题。给它一些强大的硬件，它可能会处理您正在考虑的任何负载，除非您使10gig

Eventide Project团队很高兴宣布Message DB：这是一款基于PostgreSQL中作为发布/订阅、事件溯源和事件微服务应用程序实现的、功能齐全的事

在第一部分中，我分享了在Nordstrom一直在探索和实施事件溯源作为一种架构模式。在第二部分中，我们将分享一些我们见过的常见生产者模式。

Spring框架为Java程序使用各种接口提供了简单的方法。它的JMS组件包括一些类，这些类可帮助程序等待新消息，类似于消息驱动Bean。已知使用IBM MQ时，Spring实现的默认行为不是最佳的，我想提高效率。本文显示了对

问题云中的许多解决方案都涉及运行调用服务的任务。在这种环境中，如果服务遭受间歇性重负载，则可能导致性能或可靠性问题。如果同时运行的多个任务使用相同的服务，则可能难以预测在任何给定时间点服务可能经受的请求量。服务可能会遇到需求高峰，导致服务过载并无法及

面向消息的中间件（MOM）已经成为一个小行业。MOM提供基于队列的事务处理，超过纯粹客户端/服务器事务。本论文提出四个观点： 1. 基于队列的事务处理不如直接事务处理通用。队列系统是在直接事务之上构建的，你不能再在一个队列系统上构建一个直接

目的在集成系统中，传入消息由捆绑在一起的许多项组成。例如，发票凭证包含描述交易的多个发票行（数量，提供的服务/销售商品的名称，价格等）。其他系统可能不接受此类捆绑消息。此时分配器模式可派上用场。它将采用整个文档，根据给定的标准对其进行拆分，并将单个项目发送到端点。