Notification系统及其上的事件驱动

典型的Notification一般有两种架构，一种是点对点，一种是发布订阅模型。
主要讨论发布订阅模型。

主要的类如下：
Topic，可以发布的话题。包含一个Topic的元数据。
Subscription，一个消费者（可以是系统或者用户）的一个订阅，一个订阅可以订阅一个Topic，并且可以设置一些field来filter该Topic，比如只对发布与某个时间段的Topic进行订阅。
NotificationMessage，一个话题消息的实例。

Notification支持消息的异步，支持订阅者不在线时的新生成的话题消息不会丢失（即消息的可靠传输），通过把话题消息保存在db中，同时有一个守护线程发送未发送的消息，以及多线程的技术来实现。

基于这个机制可以加入EDM（Event Driven Model）。加入EMD是为了解决如下问题。

考虑一个简单的例子，有两个系统，一个user，一个chat，chat是构建在user系统之上的。
当删除一个user时，需要考虑到对chat的影响，如user在一个chat room中则不能删除user或者强制该user退出该chat room等业务逻辑。传统上这段逻辑是在user系统中的（无论是code还是通过config）。当新加一个搭建于user之上新的系统M时，删除一个user的动作对新的系统M的影响又得通过改动user系统来完成。

这种方式有如下问题：
１　系统的依赖关系是颠倒的，user作为一个底层系统反而要调用高层的系统。
２　由于１的存在，新加系统就会影响底层user系统，user系统不稳定。需要频繁更改。

本质上一个事件的产生对系统其它模块的影响应该由受影响的模块来决定，而不是相反。
如果采用Notification机制，user在删除一个用户的时候发布一个deleteUser事件，所有对该事件感兴趣的系统监听到该事件就可以做出对应的动作。这样就解决了上面的问题。

user系统一旦设计完毕，只要适当的定义user系统可以发布的事件，以后就不需要改动了。
当有新的系统加入，只需要订阅它对user的哪些事件感兴趣就可以把对应的逻辑放在自己的模块里面，而不影响user系统。

由于Notification系统是异步的，有可能引入一些时序上的问题，如删掉一个user一分钟后才把该user从一个chat room中踢掉。有必要引入同步的机制来发布订阅事件。来保证所有订阅该事件的系统先处理各自的逻辑，然后该事件才真正发生。