基于mongoDB的capped collection的性能优化

MonitorLogging改造(消息接入)

改造前架构:

基于mongoDB的capped collection的性能优化
可以看出原来的流程中,大量业务分析,业务接入耦合在web服务层。大量操作,导致线程线性的挂起线程。

改造后:

基于mongoDB的capped collection的性能优化
 
将业务通讯抽象成为MonitorQueueManager,并将业务主题抽象放到各自的collection中。
形如:
基于mongoDB的capped collection的性能优化
基于mongoDB的capped collection的性能优化
抽象为一个结构topic,content针对业务分为若干个主题。方便以后切换到mq或者其他的队列中。
 

MonitorSchedule改造(消息集中处理)

原有处理流程

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

改造之后的流程:

基于mongoDB的capped collection的性能优化
看起来也清晰不少吧,原来的业务分成了按照业务事件进行分类。
使用监听器来处理事件本身,就有一个问题。多线程的情况下如何管理业务的处理速度。原有的瓶颈放到mongodb中了,但是,如果线程读取太快了,那么,性能的瓶颈有被移到了任务操作中了。

capped collection

这里我们先说下mongodb的capped collection:
  • 固定长度
  • LRU队列
  • 环装结构,老数据自动覆盖
  • 录入队列的数据可以与直接读写磁盘媲美
  • 基于日志形式(不可修改,不建立索引情况下速度与写磁盘相同)
所以大家可以看到,如果写到了mongoDB的collection队列之后,序列化能力使得,数据多了一个缓存方式。

代码逻辑

event

基于mongoDB的capped collection的性能优化
事件的结构很简单:
基于mongoDB的capped collection的性能优化
主要三个内容:
  • queueName 队列的名称
  • topic 消息的主题
  • source 真正消息的内容

listener

基于mongoDB的capped collection的性能优化
主要使用了spring的applicationMulticast事件广播,使用了模板方法的设计,降低耦合的同时,也大大的降低了业务实现的难度。
基于mongoDB的capped collection的性能优化
基于mongoDB的capped collection的性能优化
业务实现的逻辑,这里使用内部类来对业务进行分类,防止太多的command出现
基于mongoDB的capped collection的性能优化
命令的接口类
基于mongoDB的capped collection的性能优化

reader

基于mongoDB的capped collection的性能优化
这里将接口定义为两类:
  • 持久化层
  • 缓存层
基于mongoDB的capped collection的性能优化
基于mongoDB的capped collection的性能优化
利用修饰模式设计,共同被模板类依赖
基于mongoDB的capped collection的性能优化
抽象类实现
基于mongoDB的capped collection的性能优化
基于mongoDB的capped collection的性能优化
 
 

这样让代码编写量大大减少
我们来看下具体实现类:这样的设计相比之前的要好了不少

 
基于mongoDB的capped collection的性能优化


测试中遇到的问题

  • collection的大小限制
固定记录数假如是100条,那么对于collection来说就会存在被覆盖的情况。设置合理的长度很重要,目前设置为2个G单collection。保证缓存当天的数据,即使线程卡住或者有其他情况,也可以合理缓存。
  • 线程等停顿位置
之前在设置线程停顿时,会在读取过程中,进行sleep。这样就会对系统资源浪费,但是如果频繁的轮训又会出现一个问题,mongodb的链接资源浪费(频繁请求)。综上,采取的办法是读取有数据的时候就不休眠,在没有数据的时候才进行200毫秒的等待。
大家可以算一个账,如果一次执行等待200毫秒,处理时间为100豪秒/500条。那么就会出现做500条等待200毫秒,一秒钟只能处理1000 /(200+100)* 500=1500条数据,白白浪费了 400毫秒。所以需要改成没有数据再进行等待操作,如果有则不进行等待。
 
 
 

相关推荐