作者：李俊才 （jcLee95）：https://blog.csdn.net/qq_28550263?spm=1001.2101.3001.5343 邮箱 ：[email protected] 本文地址：https://blog.csdn.net/qq_28550263/article/details/130877457

【介绍】：本文介绍发布订阅模式的相关思想，以及第三方模块 EventEmitter 的使用。

推荐阅读： 《发布订阅模式原理及其应用（多种语言实现）》 这篇是我早前的博客，里面使用了 Powershell、Dart、Python、TypeScript 讲解或实现了一个 EventEmitter 对象。但是当时还没有考虑使用 Rust。本文多数内容直接来源于该博文，主要是将语言替换成了 Rust。

记得一九年的时候我刚刚来到深圳工作，众所周知那时候还没有爆发 新冠疫情，身边的同事们组队去香港购物是常有的事情。但是那会儿我还没有办理港澳通行证，于是年底回老家的时候去当地政务中心办理了。

办证是需要时间的，万万没想到的是二零年春节前夕——新冠疫情爆发了。当我回到深圳后的某一天接到老家政务中心的电话，通知我由于疫情的原因，通信证的办理已经被暂停了并且什么时候恢复办理还不能确定，如果愿意等待，则需要到恢复办证的时候，再通知我们。

—— 这就是一个 发布-订阅模式的典型例子。

发布-订阅 模式 模式中的多方可以分为两类，一类是消息的 发布者，另外一类是消息的 订阅者。在上面的案例中，政务中心的工作人员就是 发布者，当我表示愿意等到恢复通信证办理时，我就 向发布者订阅了 恢复办理的通知（消息），因此我时消息的 订阅者。

这样有什么好处呢：

看到了吗——相比于我们去轮询以获取消息，改用发布-订阅 模式 同时节省了我们双方地时间！

多么棒地思想！——运用于程序设计中岂不秒哉？

有一种情况也是非常常见的，那就是我不愿意继续等待消息了，也有可能是这个消息对我来说已经不重要了。这时我不再希望继续收到来自发布者的恢复办理通知，那就需要 退订。

还记得吗——当我们订阅的时候，是将我们的订阅意愿登记在发布者那边的，这样就能实现发布者在适当的时候通过查询 所有的登记记录 然后逐一通知。

因此如果一旦有用户需要退订，其实很简单，只需要订阅者在他们所登记订阅的“订阅者登陆表”中将订阅信息删除掉即可，这样下一次广播通知的时候就不会再将消息发送给退订的用户。

如果现在你好像明白 发布-订阅模式 的基本思想了——那么就请成热打铁，跟着我用程序来模拟一下证件办理的情景。

运行该脚本，输出如下：

可以看到订阅者有两个订阅者实例：jackLee（本人）、jackMa（可能是阿里出来的）共同订阅了证件办理信息。 政务服务中心（发布者）第一次发布恢复通知的时候，jackLee 和 jackMa 这两个同学都订阅了消息，因此都受到了来自该中心的通知。后来，jackMa 可能由于已经派小弟火速前往该中心取走了他的证件不需要继续订阅了，于是该中心的工作人（发布者）员调用publisher.remove_subscriber(jackMa) 从该中心的订阅者记录表中移除了 jackMa 的订阅记录。

于是，到了该中心第二次发布消息的时候，jackMa 已经不会再收到恢复证件办理消息，而 jackLee 还可以接收到恢复证件办理的消息。

在阅读本小节前请读者先自己尝试回答这个问题：Subscriber 类真的有必要实现吗？

在我们上面的代码中，Subscriber 类 实现了几乎唯一一个有用的方法：update，它的作用却是给 Publisher 类的 notifyAll 方法进行调用。

从现实生活中给一个解释： notifyAll 是消息的发布这发布消息的工具，update 是订阅用户接受到的新的定制化消息，比如同样是订阅了售房信息，但是由于不同类别的购房者订阅时所选定的楼层、大小等参数不一样，则这些不同订阅者接收到的发布结果不一样——也就表面原始的消息需要为不同的订阅者做一些 定制化 处理。在之前的代码实现中，这个消息的定制化工作就是使用 Subscriber 类的 update 方法实现的。

很显然，上表面的代码要真正实现定制化，往往不仅是参数值的不同，可能对参数的处理也不一样。因此仅仅依赖参数data是不合理的。因此我们大概是需要写多个仅仅 update 方法的实现不同的 Subscriber 类——这不太好。略好一点的办法是，让 update 方法接受的不是单纯的数据 data，而是一个 回调函数 传入 update 方法中。

先不着急修改我们的代码。对于发布者来说，似乎可以提供 更加周到 的服务——直接登记好订阅着的定制化需求处理方式，使用订阅者要求的处理方式处理好定制的消息后，直接告诉订阅者。——因此 update 这个接受表示用户定制化需求处理方式的方法可以直接合并到 发布者那边。

于是 Subscriber 类 就不需要了，现在我们只需要更新一下我们的 Publisher。更新的思路是这样的：

从 Publisher 看，需要登记的内容又多了一些。不过好在 订阅者名称（认为是唯一标识符）和 与之对于的服务（回调函数），是对应的关系，既可以一对一，也可以一对多（表示这个订阅者需要多个定制化服务）。因此我们将 Publisher 的 “记录本”改成下面的类型：

这个映射（Map）的 key 就表示 订阅者名称，而value 部分是一组函数，表示该订阅者需要的各种服务。

另外，到了这里，对于 Publisher来说，添加订阅者就转化为了 为订阅者订阅各种定制化服务 。同时反过来看，对于某个具体的订阅者 Subscriber，一旦它的服务定制数组 （Function[]）为空数组，表明他已经没有任何订阅，也不再需要接收发布者的任何消息了。

因此先前我们使用的方法名addSubscriber 不适用了，从含以上换成 addListener 似乎更加合适。

为什么呢? 我们接下来对此做进一步说明。

一直以来，我们聚焦点都在于 发布者 和 订阅者，而忽略了 引起发布者发布的事件。 这个方法接受两个参数，一个是用户名，一个是为用户新增的回调。同时必须指出的是，这个 回调 往往是需要再其调用时接受一些数据的，比如由发布者发布的某些原始数据，他们就像是时时刻刻地 监听着、守候着 发布者 发布一个事件，一旦这个 事件/消息 被发布，就 完成消息发布后为 订阅者 所提供地服务。

换一下思路，我们接着把聚焦点转移到 事件 上来。

其实从现实中看，同一个事件发生，可能意味着可能需 要干很多事，既可以 服务更多的订阅者，也可以干其它任何的工作——我们一味地想着在发布者处登记订阅者的id然后完成订阅者的需求，那么 没有区别为何事件而需要去发布这些消息！

更好的做法是 不再记录订阅者，而是记录为什么要发布消息给订阅者——也就是记录 事件。这样我们就可以在同一个事件发生的时候，通过一系列的属于该事件函数（可能一个或多个回调函数服务于同一个订阅者），完成该事件的响应，也就是回调函数们。

从这个意义上看，我们所关注所谓的 订阅者 可以看作 一个事件发布后，发布者需要调用的一组函数。而所谓 发布，实际上就是调用这组函数以 完成事件（的回调）。因此我们接下来该用 listener 表示监听事件以待执行的回调函数， event 表示事件名， emit 表示这个事件发生后需要由发布者调用函数的过程。

至此，我们的 Publisher 从一个 Subscriber 的服务员 转型成为了职业 事件的管理者，不妨给它改个名——EventEmitter。

现在我们实现一个最基础的 EventEmitter 对象：

不过很多时候我们还不满足于此，比如能够限制监听器的数量。从现实生活中打个比方，就像我们只服务一定数量的客户，一旦订满，由于资源有限，不再接收其它订阅。更贴切实际地说，就像节假日你去旅游景区地酒店订房间，对于酒店来说，一旦所有房间都预定满了，就不再接收新的订阅了——除非，有已经订阅地客人退订了它们先前已经预定地房间。

实现这样一个功能，只需要一个变量 _max_listeners 作为最大监听器数量的控制变量。在外部相应的我们需要允许用户修改和读取该变量的值，因此还要提供 set_max_listeners 和 get_max_listeners 两个方法。

你可以直接使用 cargo 包管理器安装 EventEmitter：

以下是一段包括引入 EventEmitter 和使用的例子：

运行项目：

可以看到控制台打印结果：

设置最大监听器数量。

获取最大监听器数量。

添加事件监听器。

添加事件监听器，是 on 方法的别名。

移除事件监听器。

移除事件监听器，是 off 方法的别名。

触发事件。

触发相当于“发布-订阅”模式中的“发布”，一但某个事件被触发，该事件对应得所有监听器函数都会被执行。监听器就相当于“订阅者”。

移除所有事件的所有监听器。

从指定事件监听器向量的前方插入新的监听器。该方法与使用 on、add_listener 方法添加新的监听器时，插入监听器向量的方向相反。

获取指定事件的监听器。

获取指定事件的监听器数量。