目录
发布/订阅者模式的优点发布/订阅者模式需要考虑的点发布/订阅者模式发布/订阅者模式与观察者模式熟习消息中间件的同学应该对发布/订阅模式(Publish Subscribe Pattern)并不陌生。即便你不理解消息中间件，那么在平常生活中发布/订阅模式也是非常常见的场景。
比方你打开你的微信订阅号，你订阅的作者发布的文章，会广播给每个订阅者。在这个场景里，微信公众号就是一个Pulisher，而你就是一个Subscriber，你收到的文章就是一个Message。
下面我们就一起理解一下发布/订阅模式，假如你要理解并在自己的项目中使用这个模式，或者者你对消息队列(MQ)等中间件的原理感兴趣，那么这个系列的文章就是最高效地深入浅出宝典。
发布/订阅模式(Publish Subscribe Pattern)属于设计模式中的行为(Behavioral Patterns)。
在软件架构中，发布/订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者），而是通过消息通道广播出去，让订阅改消息主题的订阅者消费到。
发布/订阅者模式最大的特点就是实现了松耦合，也就是说你可以让发布者发布消息、订阅者接受消息，而不是寻觅一种方式把两个分离的系统连接在一起。当然这种松耦合也是发布/订阅者模式最大的缺点，由于需要中间的代理商，添加了系统的复杂度。而且发布者无法实时知道发布的消息能否被每个订阅者接收到了，添加了系统的不确定性。
发布/订阅者模式的优点发布/订阅者模式的优点可以归纳为:
发布/订阅者模式可以将众多需要通信的子系统(Subsystem)解耦，每个子系统都可以独立管理。而且即便部分子系统下线了，也不会影响系统消息的整体管理。
发布/订阅者模式为应用程序提供了关注点分离。每个应用程序都可以专注于其核心功能，而消息传递基础结构负责将消息路由到每个消费者手里。
发布/订阅者模式添加了系统的可伸缩性，并提高了发送者的响应能力。起因是发送方(Publisher)可以快速地向输入通道发送一条消息，而后返回到其核心解决职责，而不必等待子系统解决完成。而后消息传递的基础结构负责确保把消息传递到每个订阅者(Subscriber)手里。
发布/订阅者模式提高了可靠性。异步的消息传递有助于应用程序在添加的负载下继续平稳运行，并且可以更有效地解决间歇性故障。
你不需要关心不同的组件是如何组合在一起的，只需他们共同遵守一份协议就可。
发布/订阅者模式允许推迟解决或者者按计划的解决。例如当系统负载大的时候，订阅者可以等到非高峰时间才接收消息，或者者根据特定的计划解决消息。
发布/订阅者模式提高了可测试性。通道可以被监视，消息可以作为整体集成测试策略的一部分而被检查或者记录。
发布/订阅者模式需要考虑的点订阅者可以在消息通道中订阅或者者取消订阅某个话题。
连接到任何消息通道必需受到安全策略的限制，以防止未经受权的客户或者应用程序窃听。
根据每条消息的内容检查和分发消息。每个订户都可以指定其感兴趣的内容。
订阅者通常只对发布者分发的消息的子集感兴趣。消息服务通常允许订户缩小以下客户接收到的消息集。
考虑允许订户通过通配符订阅多个主题。每个主题都有一个专用的输出通道，每个使用者都可以订阅所有相关主题。
发布订阅系统中的通道被视为单向的。
假如特定订户需要向发布服务器发送确认或者通信状态，请考虑使用请求/回复模式。此模式使用一个通道向订阅服务器发送消息，以及一个单独的回复通道向发布服务器进行通信。
使用者实例接收消息的顺序不肯定得到保证，也不肯定反映消息的创立顺序。
设计该系统以确保消息解决是等量的，以帮助消除对消息解决顺序的任何依赖。
有些处理方案可能需要按特定顺序解决消息。优先级队列模式提供了一种确保特定消息先于其余消息传递的机制。
格式错误的消息或者需要访问不可用资源的任务可能会导致服务实例失败。系统应防止此类消息返回到队列，否则可能导致系统故障。
同一消息可能会发送屡次。例如，发送者可能在发布消息后出现了异常，没有记录自己已经成功发送了消息，而后，发送者的新实例可能会启动并重复该消息。
消息基础结构应基于消息ID实现重复消息检测和删除（也称为重复数据消除），以便最多提供一次消息传递。
消息的生命周期可能有限。假如在这段时间内没有解决，它可能不再有价值，应该丢弃。发送方可以指定过期时间作为消息中数据的一部分。在决定能否执行与消息关联的业务逻辑之前，接收者可以检查此信息，以确保消息没有过期。
例如，消息可能会被暂时禁止，直到特定的日期和时间才被解决。
发布/订阅者模式假如你的程序只有很少的订阅者，或者者需要与子系统进行实时的交互，那么发布/订阅者模式是不适合的。
在以下情况下可以考虑使用此模式：
应用程序需要向大量消费者广播信息。例如微信订阅号就是一个消费者量庞大的广播平台。
应用程序需要与一个或者多个独立开发的应用程序或者服务通信，这些应用程序或者服务可能使用不同的平台、编程语言和通信协议。
应用程序可以向消费者发送信息，而不需要消费者的实时响应。
被集成的系统被设计为支持其数据的最终一致性模型。
应用程序需要将信息传递给多个消费者，这些消费者可能具备与发送者不同的可用性要求或者正常运行时间计划。例如你消息在上午发布了出去，消费者计划在下午才去解决这些消息。
发布/订阅者模式与观察者模式发布/订阅者模式与观察者模式是我们经常混淆的两种设计模式，可以说两种设计模式在行为上有肯定的类似性，但却是两种不同的设计模式。或者者说发布/订阅者模式是观察者模式的一种变体。
通过下图可以清晰地看到两种设计模式的不同点。
发布/订阅者模式与观察者模式主要有以下几个不同点：
在观察者模式中，主体维护观察者列表，因而主体知道当状态发生变化时如何通知观察者。然而，在发布者/订阅者中，发布者和订阅者不需要相互理解。它们只要在中间层消息代理商（或者消息队列）的帮助下进行通信。
在发布者/订阅者模式中，组件与观察者模式完全分离。在观察者模式中，主题和观察者松散耦合。
观察者模式主要是以同步方式实现的，即当发生某些事件时，主题调用其所有观察者的适当方法。发布服务器/订阅服务器模式主要以异步方式实现（使用消息队列）。
发布者/订阅者模式更像是一种跨应用程序模式。发布服务器和订阅服务器可以驻留在两个不同的应用程序中。它们中的每一个都通过消息代理商或者消息队列进行通信。
本文详情了发布者/订阅者模式的相关概念，后面几篇会详细详情具体实现。
作者：西召
链接：https://juejin.im/post/5cc9ccfff265da03474e1042#heading-0