将业务通讯抽象成为MonitorQueueManager，并将业务主题抽象放到各自的collection中。

形如：

抽象为一个结构topic,content针对业务分为若干个主题。方便以后切换到mq或者其他的队列中。

 

当时业务比较少，只有一个主处理流程，所以强耦合到main方法中，扩展基本等于0。加之之前开发比较仓促，编码注释基本没有。
现在要将monitorLoging里面的所有业务处理，放到MonitorSchedule中。业务增加，如果架构再不进行改变那即将是个灾难（维护或者业务流程新增）。

看起来也清晰不少吧，原来的业务分成了按照业务事件进行分类。

使用监听器来处理事件本身，就有一个问题。多线程的情况下如何管理业务的处理速度。原有的瓶颈放到mongodb中了，但是，如果线程读取太快了，那么，性能的瓶颈有被移到了任务操作中了。

这里我们先说下mongodb的capped collection：

利用修饰模式设计，共同被模板类依赖