dubboclub / dubbokeeper

dubbo服务管理以及监控系统
Apache License 2.0
1.29k stars 688 forks source link

monitor storage实现的几个问题(mongodb版本) #145

Open LijyCasey opened 6 years ago

LijyCasey commented 6 years ago

最近在研究dubbokeeper的monitor,做的及其复杂,有几点疑惑想要请教一下: 记录statistics流程个人理解如下: 1.monitorService collect到dubbo发来的url,进行数据拆分和处理。 2.collect处理之后调用MongoDBStatisticsStorage的storeStatistics(),MongoDBStatisticsStorage实现了一个APPLICATION_STORAGES内存缓存,校验发送过来的statistics是否在缓存内,如果不在,存入缓存,并创建ApplicationStatisticsStorage类实例,将Application信息计入MongoDB,并启动disruptor。如果已存在,直接进3. 3.调用ApplicationStatisticsStorage的addStatistics方法,向disruptor发布该条statistics。 发送流程到此结束。----------------- 4.ApplicationStatisticsStorage同时是disruptor的subscriber/publisher,所以触发了onEvent()方法,在onEvent中更新了该应用在ApplicationStatisticsStorage中相关最大值的缓存并将该条event记录到临时缓存tempStatisticsContainer中,临时缓存中的东西每隔一段时间写入mongoDB的statistics表。整个记录过程就此结束。 我的问题如下: 在2中,将application信息计入MongoDB之后,该条数据再也没有更新过,导致查询所有应用时应用类型显示错误(例如一开始接收到一条consumer url,将该应用以consumer类型计入mongoDB,此后全是provider url也不再更新其应用类型,导致显示错误) 在4中,定时存入是写在onEvent方法中,而不是另起后台任务。如果最后一条记录写入依然没有触发写入mongoDB,是不是tempStatisticsContainer缓存中的数据将永远不会写入mongoDB,直到下一条符合时间的数据写入 才会触发。 有些代码略微冗余,还在整理。而且复杂的流程不知道会不会引发事务问题。 我的建议: 个人觉得application缓存的意义不大,建议放弃ApplicationInfo的缓存和对应的collect,查询应用直接从statistics中获取,语句可能会比较复杂,但是上面这么大一堆复杂的逻辑理解起来也并不简单。 不知道这个项目是否还有人在开发,打这么大一段也希望有同样困惑的人看到这个issue能与我共同交流。谢谢