## 事件队列模式 Event Queue 事件队列模式，对消息或事件的发送与处理进行时间上的解耦。 ### ### 要点 - 事件队列：在先入先出的队列中存储一系列通知或请求。发送通知时，将请求放入队列并返回。处理请求的系统在稍晚些的时候从队列中获取请求并进行处理。这样就解耦了发送者和接收者，既静态又及时。 - 事件队列很复杂，会对游戏架构引起广泛影响。中心事件队列是一个全局变量。这个模式的通常方法是一个大的交换站，游戏中的每个部分都能将消息送过这里。 - 事件队列是基础架构中很强大的存在，但有些时候强大并不代表好。事件队列模式将状态包裹在协议中，但是它还是全局的，仍然存在全局变量引发的一系列危险。 ### ### 使用场合 - 如果你只是想解耦接收者和发送者，像观察者模式和命令模式都可以用较小的复杂度来进行处理。在需要解耦某些实时的内容时才建议使用事件队列。 - 不妨用推和拉来的情形来考虑。有一块代码A需要另一块代码B去做些事情。对A自然的处理方式是将请求推给B。同时，对B自然的处理方式是在B方便时将请求拉入。当一端有推模型另一端有拉模型时，你就需要在它们间放一个缓冲的区域。这就是队列比简单的解耦模式多出来的那一部分。队列给了代码对拉取的控制权——接收者可以延迟处理，合并或者忽视请求。发送者能做的就是向队列发送请求然后就完事了，并不能决定什么时候发送的请求会受到处理。 - 而当发送者需要一些回复反馈时，队列模式就不是一个好的选择。 ### ### 引申与参考 - 很大程度上， 事件队列模式就是广为人知的GOF设计模式中观察者模式的异步实现。 - 就像其他很多模式一样，事件队列有很多别名。 其中一个是“消息队列”。消息队列通常指代一个更高层次的实现。可以这样理解，事件队列在应用中进行交流，而消息队列通常在应用间进行交流。另一个别名是“发布/提交”，有时被缩写为“pubsub”，这个别名通常指代更大的分布式系统中的应用。 - 在有限状态机与状态模式中，往往需要一个输入流。如果想要异步响应，可以考虑用队列模式来存储它们。 - Go语言内建的“Channel”机制，其本质上就是事件队列。 - 本节内容相关的英文原文： - 本节内容相关的中文翻译：