对异步通知的定位，是作为核心业务的一种补充，应该尽量与核心业务解耦。

采用的解耦方式为“事件+监听器”。一些主流的php web框架，如laravel、yii2对“事件+监听器”的支持是“开箱即用”的，只需写少量的代码（通常是增加一些配置项）即可。

这里描述的设计思想是“解耦”，是和语言无关的，属于“设计模式”的范畴。

概念

事件

业务系统在某个时机触发事件，例如订单发货了，这时需要触发一个“订单已发货”事件。事件携带了与异步通知相关的数据，如用户信息、订单信息等，这些数据用于创建异步通知任务。

监听器

监听器负责捕捉事件并创建相关的异步通知任务。

异步通知任务

异步通知任务应有以下的属性

• 接收人
• 通知内容
• 发送时间
• 发送状态

异步通知任务应带有“锁”机制，在并发场景下也可保证同一个通知不会被多次发送给用户。
异步通知的发送时间应是可配置的，以应对需求的变化。

过滤器

过滤器用于拦截不需要发送的通知。

有一种场景：用户注册后n天内不下单则发送召回通知。这种场景需要在用户注册时触发事件，监听器捕获并创建发送时间为n天后的通知任务。如果用户在n天内下单了，则这个通知就不应该发送。

这个通知对应的过滤器就应该检查从通知的创建时间到发送时间内，用户有没有下单。

实现

工厂+配置+后台进程

配置

配置包括以下内容

• 事件对应的通知节点
• 通知节点的发送时间

工厂

工厂的职责

• 创建通知任务
• 实例化通知任务

后台进程

后台进程读取待发送的通知，将通知发送给用户，并更新通知发送状态

扩展

当新需求到来时，如当用户关注的商品降价时发送一条通知，只需在业务代码中触发一个“商品降价事件”，增加相关的配置和通知节点，即可满足需求。

不足

容易看出，这种设计思想会导致业务中的事件越来越多。但为了不侵入核心业务代码，是否可以容忍这个不足之处？