下载此文档

日志分析并行分解设计与实现.docx


文档分类:论文 | 页数:约21页 举报非法文档有奖
1/21
下载提示
  • 1.该资料是网友上传的,本站提供全文预览,预览什么样,下载就什么样。
  • 2.下载该文档所得收入归上传者、原创者。
  • 3.下载的文档,不会出现我们的网址水印。
1/21 下载此文档
文档列表 文档介绍
任务就是要完成一个日志分析应用。需求没有很明确, 只是要有这么一个东西能够满足分析收集后的日志, 将分析后的原始数据入库,作为后期分析和统计使用。在动手做之前, 我还是给这个应用作了最基本的需求定义: 灵活配置( 输入源, 输出目标, 分析器的实现等), 高效( 并行任务分解)。就这两点能够做到, 那么将来需求如何变化都可以适应。 Tiger 的 Concurren t 包是满足后面那项最好的实现, 里面的线程池, 异步服务调用, 并发控制都能够极好的完成并行任务分解的工作。 J2SE 7的 Concurrent 包中将会增加 fork-join 风格的并行分解库, 其实这个是更细粒度的任务分解, 同时能够在当前多 CPU 的情况下提高执行效率,充分利用 CPU 的一种实现。背景: 由于服务路由应用访问量十分大, 即时的将访问记录入库对于路由应用本身以及数据库来说无疑都会产生很大的压力和影响。因此考虑首先将访问信息通过 log4 j 记录在本地(当然自己需要定制一下 Log4j 的 Appender 和 Filter ),然后通过服务器的定时任务脚本来将日志集中到日志分析应用所在的机器上( 这里通过配置可以决定日志是根据什么时间间隔来产生新文件) 。日志分析应用就比较单纯的读取日志, 分析日志, 输出分析结果( 包括写入数据库或者是将即时统计信息存入到集中式缓存 Memcached 中)。网络结构图如下: Concurrent 概述: 看 Java 的 Doc 很容易就理解了 Concurrent , 这里我只是大致的说一下几个自己在应用中使用的接口: BlockingQueue<E> :看看名字就知道了,阻塞式队列, 可以设置大小。适合于生产者和消费者模式, 生产者在队列满时阻塞, 消费者在队列空时阻塞。在日志分析应用开发中被用于分析任务( 生产者) 和输出任务(消费者)之间的分析结果存储通道。 Callable<V> :任何需要执行的任务都可以定义成 Callable ,类似于线程的 Runnabl e 接口,可以被 Service Executor 指派给内部的线程异步执行, 并且返回对象或者抛出异常。在日志分析应用开发中, 非定时性的任务都定义成为此类型。 ConcurrentMap<K,V> :这个以前常常使用, 因 为效率要远远高于 和 synchronized 。后面还会提到实践中的几个实用的技巧来防止在高并发的情况下出现问题。在日志分析应用中, 此类型的 Map 作为保存日志文件分析状态的缓存( 日志文件分为两种状态: 分析中, 分析结束。如果不存在于 Map 中就认为尚未分析, 那么将其纳入 Map 然后启动分析处理线程工作, 如果存在于 Map 中标示为分析中, 那么将不会再分析此文件, 如果分析结束并且被输出, 将会标示此文件分析结束, 异步清理线程将会定时根据策略删除或移动文件)。 ExecutorService :内置线程池,异步执行指派任务,并可以根据返回的 Future 来跟踪执行情况。在日志分析应用开发中, 被用于非定时性任务执行。 ScheduledExecutorService :内置线程池, 定时异步执行指派任务, 并可以根据返回的 Future 来跟踪执行情况。在日志分析应用开发中,被用于定时性任务执行。以上就是被使用到的接口, 具体实现策略配置就不在此赘述了。整体结构设计: 整体设计还是基于开始设定的两个原则: 灵活配置, 高效性( 任务分解, 并行流水线执行) 。说到任务分解又会想起读书时候的离散数学中关键路径等等。任务分解还是要根据具体情况来分析和设计, 不然并行不但不会提高效率,反而还降低了处理效率。就日志分析来看, 主要的处理过程可以分成这么几个任务: 1. 检查日志来源目录,锁定需要分析的文件。( 执行需要时间很短, 可通过定时间隔执行)。 2. 分析已经被锁定的日志文件,产生分析结果。( 执行需要时间根据日志文件大小来决定, 因此需要线程异步执行, 结果根据设定拆分成细粒度包, 降低输出线程等待时间)。 3. 检查分析结果队列。(执行需要时间很短, 当前是配置了 SingleThreadExecuto r 来执行检查阻塞队列的工作, 同时获取到分析结果包以后立刻创建线程来执行输出任务) 4. 输出分析结果,如果输出成功,将分析过的日志文件在日志文件状态缓存中的状态更新为已分析。( 执行时间根据输出情况来定,当前实现的是批量输出到数据库中, 根据配置来批量提交入库, 后续还会考虑实时统计到集中式 Cache 作为监控使用)。 5. 清理分析日志文件。( 执行时间较短, 设定了定时线程池执行清理任务, 根据策

日志分析并行分解设计与实现 来自淘豆网www.taodocs.com转载请标明出处.

相关文档 更多>>
非法内容举报中心
文档信息
  • 页数21
  • 收藏数0 收藏
  • 顶次数0
  • 上传人ranfand
  • 文件大小187 KB
  • 时间2017-03-26