巅峰战队|PowerJob日志饱受好评的秘诀:小但实用的分布式日志系统( 三 )


3.3 存储与排序引入 H2 之后 , powerjob-server 处理在线日志的流程如下:

  1. 接收来自 worker 的日志数据 , 直接写入内嵌数据库 H2 中
  2. 在线调用时 , 通过 SQL 查询语句的 order by log_time 功能 , 完成日志的排序和输出
可见 , 合适的技术选型能让问题的解决简单很多~
四、一些其他的优化以上介绍了 PowerJob 分布式日志组件的核心原理和实现 , 当然 , 在实际使用中 , 还引入了许多优化 , 限于篇幅 , 这里简单提一下 , 有兴趣的同学可以自己去看源码~
  • 高频率在线访问降压:如果每次用户查看日志 , 都需要从数据库中查询并输出 , 这个效率和速度都会非常慢 。 毕竟当数据量达到一定程度时 , 光是磁盘 I/O 就得花去不少时间 。 因此 , powerjob-server 会为每次查询生成缓存文件 , 一定时间范围内的日志查询 , 会通过文件缓存直接返回 , 而不是每次都走 DB 查询方案 。
  • 日志分页:成百上千万条数据的背后 , 生成的文件大小也以及远远高于正常网络带宽所能轻松承载的范围了 。 因此 , 为了在前端控制台快速显示在线日志 , 需要引入分页功能 , 一次显示部分日志数据 。 这也是一项较为复杂的文件操作 。
  • 远程存储:所有日志都存在 server 本地显然不符合高可用的设计目标 , 毕竟换一台 server 就意味着所有的日志数据都丢了 , 因此 PowerJob 引入了 mongoDB 作为日志的持久化存储介质 。 mongodb 支持用户直接使用其底层的分布式文件系统 GridFS , 经过我仔细的考量 , 认为这是一个可接受且较为强大的扩展依赖 , 因此选择引入 。
五、最后好了 , 本期的内容就到这里结束了 , 下一期 , 我将会大家讲述 PowerJob 作为一个各个节点时刻需要进行通讯的框架 , 底层序列化框架该如何选择 , 具体的序列化方案又该如何设计~
那么我们下期再见喽~


推荐阅读