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

[LijyCasey]

最近在研究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能与我共同交流。谢谢