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