大家好！
开始翻译一本小书：
“
了解消息代理 ”，
作者：Jakub Korab，出版商：O'Reilly Media，Inc.，出版日期：2017年6月，ISBN：9781492049296。
从介绍到本书：
“ ......
本书将通过比较和对比两种流行的代理技术：Apache ActiveMQ和Apache Kafka，来教您谈论代理上的消息传递系统。在这里，您将找到一些使用和开发激励措施的例子，这些诱因使他们的开发人员使用完全不同的方法在同一个领域内–与中间代理在系统之间进行消息传递。我们将从头开始研究这些技术，并重点介绍各种设计方案的影响。您将对这两种产品有深入的了解， 了解如何使用和不应使用它们，以及了解将来在考虑其他消息传递技术时要寻找的内容 ...”
迄今为止翻译的部分：
第1章简介第2章ActiveMQ第三章。卡夫卡翻译完成： tele.gg/middle_java我将翻译完成的章节。
第1章
引言
系统间消息传递是IT领域了解最少的领域之一。 作为开发人员或架构师，您可能熟悉各种框架和数据库。 但是，您可能只对基于代理的消息传递技术的工作方式熟识。 如果您有这种感觉，请放心，您相处融洽。
人们通常与消息传递基础结构的联系非常有限。 他们通常会连接到很久以前创建的系统，或者从Internet下载分发工具包，将其安装在PROM中并开始为其编写代码。 在PROM中启动基础结构后，结果可能会好坏参半：失败期间的消息丢失，发送无法按预期工作，或者代理“挂起”您的生产者或不向您的消费者发送消息。
听起来很熟悉？
常见的情况是您的消息传递代码暂时正常工作。 直到停止工作。 这个时期使人们保持警惕，并产生一种错误的安全感，从而导致基于关于技术基本行为的错误观念而产生的更多代码。 当某些问题开始出现问题时，您将面临一个令人不安的事实：您真的不了解产品的基本行为或作者选择的折衷方案，例如性能与可靠性，事务性与水平可伸缩性。
在不深入了解经纪人如何工作的情况下，人们对其消息传递系统做出了看似合理的声明，例如：
- 系统将永远不会丢失消息
- 消息将被顺序处理
- 添加消费者将使系统更快
- 邮件将只发送一次。
不幸的是，其中一些陈述是基于仅在某些情况下适用的假设，而其他陈述则完全是错误的。
本书将通过比较和对比两种流行的代理技术：Apache ActiveMQ和Apache Kafka，教您如何谈论基于代理的消息传递系统。 在这里，我们将描述一些使用和开发激励措施的示例，这些诱因使他们的开发人员在同一领域使用完全不同的方法-使用中间代理在系统之间进行消息传递。 我们将从头开始研究这些技术，并重点介绍各种设计方案的影响。 您将对这两种产品有深入的了解，将了解如何使用和不应使用它们，以及将来考虑使用其他消息传递技术时将要寻找的内容。
在开始之前，我们先看一下基础知识。
什么是消息传递系统，为什么需要它
为了使两个应用程序能够相互通信，它们必须首先定义一个接口。 该接口的定义包括选择传输方式或协议（例如HTTP，MQTT或SMTP），以及协商系统将交换的消息格式。 它可以是一个严格的过程，例如使用消息的有效载荷需求定义XML模式，也可以不那么正式，例如，两个开发人员之间达成的协议，即HTTP请求的某些部分将包含客户端标识符。 。
只要系统之间的消息格式和发送顺序一致，它们就可以彼此交互，而不必担心另一个系统的实现。 这些系统的内部结构（例如编程语言或使用的框架）可能会随时间变化。 只要合同本身得到支持，交互就可以从另一端继续不变。 通过此接口，两个系统实际上已断开连接（分离）。
通常，消息系统在两个系统之间提供中介的参与，该系统进行交互以进一步使发送者与一个或多个接收者脱离（分离）。 同时，消息传递系统允许发件人发送消息，而无需知道收件人在哪里，他是否处于活动状态或有多少个收件人。
让我们看一下消息传递系统解决的各种问题的两个类比，并介绍一些基本术语。
点对点
亚历山德拉去邮局给亚当寄了一个包裹。 她走到窗前，递给员工一个包裹。 员工拿起包裹并给亚历山德拉一张收据。 亚当在寄送包裹时不需要在家。 亚历山德拉（Alexandra）有信心，该包裹将在将来的某个时候交付给亚当，并且可以继续做自己的事情。 后来，在某个时候，亚当收到了包裹。
这是
点对点消息传递模型的示例。 这里的邮局充当包裹分发机制，确保每个包裹都被递送一次。 邮局的使用将包裹的发送与包裹的发送分开了。
在经典消息传递系统中，点对点模型是通过
队列实现的。 队列充当一个或多个使用者可以订阅的FIFO缓冲区（先进先出）。 每个消息仅传递给
一个订阅的使用者 。 队列通常尝试在使用者之间公平地分配消息。 只有一个消费者会收到此消息。
术语“耐用”适用于队列。
可靠性是该服务的一项功能，可确保消息传递系统在活动订户不存在的情况下保存消息，直到使用者订阅队列以进行消息传递为止。
可靠性经常与
持久性相混淆，尽管这两个术语可以互换使用，但是它们执行不同的功能。 持久性确定消息系统是否在接收和发送给使用者之间的任何形式的存储中交换消息。 发送到队列的消息可能是持久的，也可能不是持久的。
当用例需要对消息执行一次性操作时，将使用点对点消息传递。 一个示例是将资金存入帐户或完成交货订单。 稍后我们将讨论为何消息传递系统本身无法提供一次性传递，以及为什么队列充其量只能
至少提供一次传递保证。
发布者订阅者
加布里埃拉拨打会议电话。 当她连接到会议时，她会听到发言人所说的一切以及通话中的其他参与者。 当她关闭时，她会跳过所说的内容。 重新连接后，她继续听到他们说的话。
这是
发布-订阅消息传递模型的示例。 会议充当广播机制。 通话中的人不在乎当前有多少人加入该呼叫-系统确保当前连接的任何人都听到了正在说的话。
在经典消息传递系统中，发布-订阅消息传递模型是通过
topic实现的。 本主题提供与会议机制相同的广播方法。 当消息发送到主题时，它会分
发给所有订阅的用户 。
主题通常
不可靠（不耐久） 。 就像不听电话会议上的讲话的听众一样，当听众断开连接时，主题订户会跳过脱机时发送的所有消息。 由于这个原因，可以说主题为每个消费者提供了
不超过一次的交付保证。
当消息本质上是信息性消息时，通常使用发布-订阅消息传递，并且丢失一条消息不是特别重要。 例如，主题可以每秒发送一次来自一组传感器的温度读数。 一个对当前温度感兴趣并订阅该主题的系统将不会担心是否错过一条消息，而另一个系统将在不久的将来到来。
混合模型
商店的网站将订单消息放置在消息队列中。 这些消息的主要使用者是执行系统。 此外，审核系统必须具有这些订单消息的副本，以便后续跟踪。 即使系统本身在一段时间内不可用，两个系统也不能跳过消息。 网站不应该知道其他系统。
使用场景通常需要将发布-订阅和点对点消息传递模型结合起来，例如，当多个系统需要消息的副本，并且同时需要可靠性和持久性来防止消息丢失时。
在这些情况下，需要一个目的地（队列和主题的通用术语），该目的地主要将消息作为主题进行分发，以便将每个消息发送到对这些消息感兴趣的单独系统，而且每个系统都可以定义几个接收到传入消息（更像是队列）的使用者。 在这种情况下，阅读的类型
对于每个感兴趣的方都是
一次 。 这些混合收件人通常需要耐用性，因此，如果使用者断开连接，则在重新连接使用者之后会接收到此时发送的消息。
混合模型并不是什么新鲜事物，可以在大多数消息传递系统中使用，包括ActiveMQ（通过组合了主题和队列的虚拟或复合目标）和Kafka（隐式地作为其收件人设计的基本属性）。
既然我们已经有了一些基本的术语，并且已经了解了消息传递系统可能有用的地方，那么让我们继续讲细节。
翻译完成： tele.gg/middle_java下一部分：
第2章。ActiveMQ待续...