您好！
我开始翻译一本小书：
«”
作者：Jakub Korab，出版商：O'Reilly Media, Inc.，出版日期：2017 年 9781492049296 月，ISBN：XNUMX。
从书的简介来看：
“... 本书将教您如何思考代理消息传递系统，比较和对比两种流行的代理技术：Apache ActiveMQ 和 Apache Kafka。 它将概述导致开发人员在同一领域采用截然不同的方法的用例和开发激励措施——通过中间代理在系统之间发送消息。 我们将从头开始研究这些技术，并强调各种设计选择的影响。 您将对这两种产品有深入的了解，了解它们应该如何使用和不应该如何使用，以及了解未来考虑其他消息传递技术时要寻找什么 ......“
目前已翻译的部分：
我将在翻译完成的章节后发布它们。
第十九章
介绍
系统间消息传递是 IT 领域最不为人所知的领域之一。 作为一名开发人员或架构师，您可能非常熟悉各种框架和数据库。 但是，您可能对基于代理的消息传递技术的工作原理只是略知一二。 如果你有这样的感觉，别担心，你们有很好的伙伴。
人们通常与消息传递基础设施的接触非常有限。 他们经常连接到很久以前创建的系统，或者从互联网下载发行版，将其安装在 PROM 中并开始为其编写代码。 在 PROM 中运行基础架构后，结果可能会很复杂：消息因故障而丢失、发送无法按您的预期工作，或者代理“挂起”您的生产者或不向您的消费者发送消息。
听起来很熟悉？
一个常见的场景是您的消息传递代码暂时运行良好。 直到它停止工作。 这个时期使人们放松警惕，产生一种错误的安全感，导致更多的代码基于对技术基本行为的错误信念。 当事情开始出错时，您将面临一个难以忽视的事实：您还没有真正理解产品的底层行为或作者选择的权衡，例如性能与可靠性，或事务性与水平可扩展性。
如果没有深入了解经纪人的工作原理，人们就会对他们的消息系统做出看似合理的陈述，例如：
- 系统永远不会丢失消息
- 消息将按顺序处理
- 添加消费者将使系统更快
- 消息只会发送一次
不幸的是，其中一些陈述是基于仅适用于某些情况的假设，而另一些则完全不正确。
本书将教您如何思考基于代理的消息传递系统，比较和对比两种流行的代理技术：Apache ActiveMQ 和 Apache Kafka。 它将概述导致开发人员在同一领域采用截然不同的方法的用例和开发激励措施——通过中间代理在系统之间发送消息。 我们将从头开始研究这些技术，并强调各种设计选择的影响。 您将深入了解这两种产品，了解它们应该如何使用和不应该如何使用，以及了解未来考虑其他消息传递技术时要寻找什么。
在开始之前，我们先回顾一下基础知识。
什么是消息传递系统以及为什么需要它？
为了使两个应用程序能够相互通信，它们必须首先定义一个接口。 定义此接口涉及选择传输或协议（例如 HTTP、MQTT 或 SMTP），以及协商将在系统之间交换的消息格式。 这可能是一个严格的过程，例如定义具有消息有效负载成本要求的 XML 模式，也可能不太正式，例如两个开发人员之间达成的协议，即 HTTP 请求的某些部分将包含客户端标识符。
只要系统之间消息的格式和发送顺序一致，就可以相互通信，而不必担心对方系统的实现。 这些系统的内部结构，例如所使用的编程语言或框架，可能会随着时间的推移而改变。 只要合约本身得到维护，交互就可以继续进行，而无需对方进行更改。 两个系统通过该接口有效地解耦（分离）。
消息传递系统通常涉及两个系统之间的中介，这两个系统进行交互以进一步将发送者与一个或多个接收者分离（分离）。 在这种情况下，消息传递系统允许发送者发送消息，而无需知道接收者在哪里、他是否处于活动状态或有多少个实例。
让我们看一下消息系统解决的问题类型的几个类比，并介绍一些基本术语。
点至点
亚历山德拉去邮局给亚当寄包裹。 她走到窗口，把包裹递给员工。 员工拿起包裹并给了亚历山德拉一张收据。 包裹寄出时，亚当不需要在家。 亚历山德拉（Alexandra）相信包裹将在未来某个时候交付给亚当（Adam），并可以继续处理她的生意。 后来，亚当收到了一个包裹。
这是消息传递模型的示例 点对点。 这里的邮局充当包裹分发机制，确保每个包裹都投递一次。 使用邮局将发送包裹的行为与包裹的递送分开。
在经典的消息系统中，点对点模型是通过 队列。 队列充当 FIFO（先进先出）缓冲区，可由一个或多个消费者订阅。 每条消息仅传递 给订阅的消费者之一。 队列通常尝试在消费者之间公平地分发消息。 只有一个消费者会收到此消息。
术语“持久”适用于队列。 可靠性 是一个服务属性，可确保消息传递系统在没有活动订阅者的情况下保留消息，直到消费者订阅队列以进行消息传递。
可靠性经常与 坚持 尽管这两个术语可以互换使用，但它们具有不同的功能。 持久性决定消息系统在接收消息和将消息发送给消费者之间是否将消息写入某种存储。 发送到队列的消息可能是持久的，也可能不是持久的。
当用例需要对消息执行一次性操作时，使用点对点消息传递。 示例包括将资金存入帐户或完成交货订单。 稍后我们将讨论为什么消息系统本身无法提供一次性交付以及为什么队列最多只能提供交付保证 至少一次.
发布者-订阅者
加布里埃拉拨打会议号码。 当她连接到会议时，她可以听到发言人以及其他通话参与者所说的所有内容。 当她调出音调时，她就会错过所说的话。 重新连接后，她继续听到正在说的话。
这是消息传递模型的示例 发布-订阅。 电话会议充当广播机制。 说话的人并不关心当前有多少人正在通话 - 系统确保当前连接的任何人都会听到正在说的内容。
在经典的消息系统中，发布-订阅消息模型是通过以下方式实现的： 最高额。 Topic提供了与会议机制相同的广播方式。 当消息发送到某个主题时，该消息就会被分发 对于所有订阅用户.
话题通常是 不可靠（不耐用）。 就像听众在断开连接时无法听到电话会议中所说的内容一样，主题订阅者也会错过离线时发送的任何消息。 因此，我们可以说主题提供了交付保证 不超过一次 对于每个消费者。
当消息本质上是信息性的并且一条消息的丢失不是特别严重时，通常使用发布-订阅消息传递。 例如，主题可以每秒从一组传感器传输一次温度读数。 对当前温度感兴趣并订阅某个主题的系统不会担心它是否错过了一条消息 - 另一个消息将在不久的将来到达。
混合模型
该商店的网站将订单消息放入“消息队列”中。 这些消息的主要消费者是执行系统。 此外，审计系统应该有这些订单消息的副本，以供后续跟踪。 两个系统都不允许消息通过，即使系统本身在一段时间内不可用。 该网站不应该知道其他系统。
使用案例通常需要发布-订阅和点对点消息传递模型的组合，例如当多个系统需要消息副本并且需要可靠性和持久性来防止消息丢失时。
这些情况需要一个目的地（队列和主题的通用术语），该目的地基本上将消息作为主题进行分发，以便将每条消息发送到对这些消息感兴趣的单独系统，而且每个系统可以定义多个接收传入消息的消费者消息，这更像是一个队列。 本例中的读取类型是 每个利益相关者一次。 这些混合目的地通常需要持久性，以便如果消费者离线，则在消费者重新连接后会收到当时发送的消息。
混合模型并不新鲜，可以在大多数消息传递系统中使用，包括 ActiveMQ（通过结合主题和队列的虚拟或复合目标）和 Kafka（隐式地，作为其目标设计的基本属性）。
现在我们已经了解了一些基本术语并了解了消息传递系统的用途，接下来让我们开始讨论细节。
翻译完成：
以下翻译部分：
待续...
来源： habr.com