《游戏编程模式》学习笔记（十四）事件队列 Event Queue

定义

事件队列在队列中按先入先出的顺序存储一系列通知或请求。 发送通知时，将请求放入队列并返回。 处理请求的系统之后稍晚从队列中获取请求并处理。 这解耦了发送者和接收者，既静态又及时。

要点

• 事件队列：在先入先出的队列中存储一系列通知或请求。发送通知时，将请求放入队列并返回。处理请求的系统在稍晚些的时候从队列中获取请求并进行处理。 这样就解耦了发送者和接收者，既静态又及时。
• 事件队列很复杂，会对游戏架构引起广泛影响。中心事件队列是一个全局变量。这个模式的通常方法是一个大的交换站，游戏中的每个部分都能将消息送过这里。
• 事件队列是基础架构中很强大的存在，但有些时候强大并不代表好。事件队列模式将状态包裹在协议中，但是它还是全局的，仍然存在全局变量引发的一系列危险。
使用场合
• 如果你只是想解耦接收者和发送者，像观察者模式和命令模式都可以用较小的复杂度来进行处理。在需要解耦某些实时的内容时才建议使用事件队列。
• 不妨用推和拉来的情形来考虑。有一块代码A需要另一块代码B去做些事情。对A自然的处理方式是将请求推给B。同时，对B自然的处理方式是在B方便时将请求拉入。当一端有推模型另一端有拉模型时，你就需要在它们间放一个缓冲的区域。 这就是队列比简单的解耦模式多出来的那一部分。队列给了代码对拉取的控制权——接收者可以延迟处理，合并或者忽视请求。发送者能做的就是向队列发送请求然后就完事了，并不能决定什么时候发送的请求会受到处理。
• 而当发送者需要一些回复反馈时，队列模式就不是一个好的选择。

引申与参考

• 很大程度上，事件队列模式就是广为人知的GOF设计模式中观察者模式的异步实现。
• 就像其他很多模式一样，事件队列有很多别名。其中一个是“消息队列”。 消息队列通常指代一个更高层次的实现。可以这样理解，事件队列在应用中进行交流，而消息队列通常在应用间进行交流。另一个别名是“发布/提交”，有时被缩写为“pubsub”，这个别名通常指代更大的分布式系统中的应用。
• 在有限状态机与状态模式中，往往需要一个输入流。如果想要异步响应，可以考虑用队列模式来存储它们。
• Go语言内建的“Channel”机制，其本质上就是事件队列。

参考文章
原书链接