在优锐课的学习分享中，让我们看一下消息传递模式，例如数据类型通道，无效消息和无效消息，崩溃验证和有保证的传递以及非消息客户端。

前言

当两个或多个应用程序要交换数据时，它们通过通过连接到其他应用程序的通道发送数据来进行交换。发送数据的应用程序可能不知道哪个应用程序将接收数据，但是通过选择一个特定的通道来发送数据，发送方知道接收方将是通过在其上查找数据来查找此类数据的接收方渠道。

在设计应用程序时，开发人员必须知道在何处放置什么类型的数据以与其他应用程序共享该数据，同样也要在哪里寻找来自其他应用程序的哪些类型的数据。这些通信路径无法在运行时动态创建和发现。它们需要在设计时达成共识，以便应用程序知道其数据来自何处以及数据将到达何处。一个例外是请求-答复中的答复渠道。请求者可以创建或获得应答者不知道的新通道，将其指定为请求消息的返回地址，然后应答者可以使用它。另一个例外是支持分层通道的邮件系统实现。接收者可以订阅层次结构中的父对象，然后发送者可以将接收者不知道的内容发布到新的子频道，订阅者仍将接收消息。

首先，应用程序确定消息传递系统将需要提供的渠道。后续的应用程序将尝试在可用的通道周围设计其通信，但是，如果这不切实际，则将需要添加其他通道。当一组应用程序已经使用了一组特定的通道，而新的应用程序希望加入时，它们也将使用现有的一组通道。现有应用程序添加新功能时，它们可能需要新渠道。

另一个常见的混乱原因是消息通道是单向还是双向。从技术上讲，两者都不是；通道更像是一些应用程序向其中添加数据而其他应用程序从中获取数据的存储桶。但是由于数据是在从一个应用程序传播到另一个应用程序的消息中，所以给出了通道方向，使其成为单向的。如果某个通道是双向的，则意味着一个应用程序既会向同一通道发送消息，又会从同一通道接收消息，因为该应用程序倾向于继续消耗自己的消息，而该消息原本应该发送给其他应用程序。因此，出于所有实际目的，通道是单向的。结果，对于两个应用程序进行双向对话，它们将需要两个通道，每个方向一个。

因此，在消息传递系统中使用了不同类型的通道。消息通道是消息传递系统的基本体系结构模式，从根本上用于在应用程序之间交换数据。

1、一对一或一对多

当应用程序仅与一个其他应用程序或对该数据感兴趣的任何其他应用程序共享数据时。 然后你可以使用点对点通道。 这不能保证在该通道上发送的每条数据都必定会到达同一接收器，因为该通道可能有多个接收器。 但它确实确保仅其中一个应用程序可以接收任何一条数据。

如果所有接收者都需要接收数据，请使用发布-订阅通道。 然后，数据被通道有效地复制，并将其传递到每个接收器。 发送者简单地将事件广播给所有感兴趣的接收者。

2、数据类型（数据类型通道）

邮件内容必须符合某种类型，以便接收者理解数据的结构。 数据类型通道是一个原则，通道上的所有数据必须具有相同的类型。 这是消息传递系统需要大量渠道的主要原因。 如果数据可以是任何类型，则消息传递系统在任何两个应用程序之间仅需要一个通道（在每个方向上）。

3、无效和无效的消息

消息系统可以确保正确传递消息，但是不能保证接收方知道如何处理。 接收者对数据的类型和含义有期望。 但是，它可以做的是将奇怪的消息放在专门指定的“无效消息通道”上，希望监视该通道的某些实用程序可以提取该消息并弄清楚该如何处理。

许多消息传递系统具有类似的内置功能，即死信通道，用于成功发送但最终无法成功传递的消息。 再次，希望一些监视该通道的实用程序将知道如何处理无法传递的消息。

4、防撞证明

如果消息传递系统崩溃或为了维护而关闭。 备份并运行时，这些消息仍将保留在其通道中。 默认情况下，否； 通道将其消息存储在内存中。 但是，``保证传递''使通道保持持久状态，以便其消息存储在磁盘上。 这会影响性能，但会使消息传递更加可靠。

5、非邮件客户端

如果应用程序无法连接到消息传递系统，但仍想参与消息传递。 但是，如果消息传递系统可以通过其用户界面，其业务服务API，数据库或通过网络连接（例如TCP / IP或HTTP）以某种方式连接到应用程序，则可以使用消息传递系统上的``通道适配器''来 将一个通道（或一组通道）连接到应用程序，而无需修改应用程序，也不必在应用程序所在的同一台计算机上运行消息传递客户端。

有时，“非消息客户端”实际上是一个消息客户端，仅用于其他消息系统。 在这种情况下，作为两个消息传递系统上的客户端的应用程序可以在两者之间建立一个消息传递桥，从而将它们有效地连接到一个复合消息传递系统中。

总结

文章写到这里，相信大家现在能有一个简单的描述了。如有不足之处，欢迎补充评论。