MonitorLogging改造(消息接入)
改造前架构：
可以看出原来的流程中，大量业务分析，业务接入耦合在web服务层。大量操作，导致线程线性的挂起线程。
改造后：
将业务通讯抽象成为MonitorQueueManager，并将业务主题抽象放到各自的collection中。
形如：
抽象为一个结构topic,content针对业务分为若干个主题。方便以后切换到mq或者其他的队列中。
MonitorSchedule改造（消息集中处理）
原有处理流程
当时业务比较少，只有一个主处理流程，所以强耦合到main方法中，扩展基本等于0。加之之前开发比较仓促，编码注释基本没有。
现在要将monitorLoging里面的所有业务处理，放到MonitorSchedule中。业务增加，如果架构再不进行改变那即将是个灾难（维护或者业务流程新增）。
改造之后的流程：
看起来也清晰不少吧，原来的业务分成了按照业务事件进行分类。
使用监听器来处理事件本身，就有一个问题。多线程的情况下如何管理业务的处理速度。原有的瓶颈放到mongodb中了，但是，如果线程读取太快了，那么，性能的瓶颈有被移到了任务操作中了。
capped collection
这里我们先说下mongodb的capped collection：
- 固定长度
- LRU队列
- 环装结构，老数据自动覆盖
- 录入队列的数据可以与直接读写磁盘媲美
- 基于日志形式（不可修改，不建立索引情况下速度与写磁盘相同）
其实它的最大优点也是最大缺点，
- 建立索引效率将为普通的collection，查询效率低下
- 不支持分片，再哪个mongo建，就只能在哪个mongo下用
所以大家可以看到，如果写到了mongoDB的collection队列之后，序列化能力使得，数据多了一个缓存方式。
代码逻辑
event
事件的结构很简单：
主要三个内容：
- queueName 队列的名称
- topic 消息的主题
- source 真正消息的内容
listener
主要使用了spring的applicationMulticast事件广播,使用了模板方法的设计，降低耦合的同时，也大大的降低了业务实现的难度。
业务实现的逻辑，这里使用内部类来对业务进行分类，防止太多的command出现
命令的接口类
reader
这里将接口定义为两类：
抽象类实现
这样让代码编写量大大减少
我们来看下具体实现类：这样的设计相比之前的要好了不少
测试中遇到的问题
固定记录数假如是100条，那么对于collection来说就会存在被覆盖的情况。设置合理的长度很重要，目前设置为2个G单collection。保证缓存当天的数据，即使线程卡住或者有其他情况，也可以合理缓存。 之前在设置线程停顿时，会在读取过程中，进行sleep。这样就会对系统资源浪费，但是如果频繁的轮训又会出现一个问题，mongodb的链接资源浪费（频繁请求）。综上，采取的办法是读取有数据的时候就不休眠，在没有数据的时候才进行200毫秒的等待。 大家可以算一个账，如果一次执行等待200毫秒，处理时间为100豪秒/500条。那么就会出现做500条等待200毫秒，一秒钟只能处理1000 /（200+100）* 500=1500条数据，白白浪费了 400毫秒。所以需要改成没有数据再进行等待操作，如果有则不进行等待。
基于mongoDB的capped collection的性能优化
原文：http://blog.csdn.net/xiamizy/article/details/41078405
