基于mongoDB的capped collection的性能优化

MonitorLogging改造(消息接入)

改造前架构：

能够看出原来的流程中，大量业务分析，业务接入耦合在web服务层。大量操做，致使线程线性的挂起线程。

改造后：

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

形如：

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

MonitorSchedule改造（消息集中处理）

原有处理流程

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

改造以后的流程：

看起来也清晰很多吧，原来的业务分红了按照业务事件进行分类。

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

capped collection

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

• 固定长度
• LRU队列
• 环装结构，老数据自动覆盖
• 录入队列的数据能够与直接读写磁盘媲美
• 基于日志形式（不可修改，不创建索引状况下速度与写磁盘相同）

因此你们能够看到，若是写到了mongoDB的collection队列以后，序列化能力使得，数据多了一个缓存方式。

代码逻辑

event

事件的结构很简单：

主要三个内容：

• queueName 队列的名称
• topic 消息的主题
• source 真正消息的内容

listener

主要使用了spring的applicationMulticast事件广播,使用了模板方法的设计，下降耦合的同时，也大大的下降了业务实现的难度。

业务实现的逻辑，这里使用内部类来对业务进行分类，防止太多的command出现

命令的接口类

reader

这里将接口定义为两类：

• 持久化层
• 缓存层

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

抽象类实现

这样让代码编写量大大减小
咱们来看下具体实现类：这样的设计相比以前的要好了很多

测试中遇到的问题

• collection的大小限制

固定记录数假如是100条，那么对于collection来讲就会存在被覆盖的状况。设置合理的长度很重要，目前设置为2个G单collection。保证缓存当天的数据，即便线程卡住或者有其余状况，也能够合理缓存。

• 线程等停顿位置

以前在设置线程停顿时，会在读取过程当中，进行sleep。这样就会对系统资源浪费，可是若是频繁的轮训又会出现一个问题，mongodb的连接资源浪费（频繁请求）。综上，采起的办法是读取有数据的时候就不休眠，在没有数据的时候才进行200毫秒的等待。

你们能够算一个帐，若是一次执行等待200毫秒，处理时间为100豪秒/500条。那么就会出现作500条等待200毫秒，一秒钟只能处理1000 /（200+100）* 500=1500条数据，白白浪费了 400毫秒。因此须要改为没有数据再进行等待操做，若是有则不进行等待。