本文给大家讲述的是我们如何去构建一个日志系统，用到了那些技术，为什么用这些技术，并且讲述了遇到的问题及优化的过程，希望给大家在实践中能够提供一些参考。
最近在维护一个有关于日志的项目，这个项目是负责收集、处理、存储、查询京东卖家相关操作的日志，我们这里就叫它“卖家日志”。在日常的开发过程中，可能我们对日志这个词并不陌生，例如我们常接触到的log4j、slf4j等等，这些日志工具通常被我们用来记录代码运行的情况，当我们的系统出了问题时，我们可以通过查看日志及时的定位问题的所在，从而很快的解决问题，今天我所讲的卖家日志，又与这个有些许的不同，卖家日志是用来记录卖家对系统各个功能的操作情况，例如：张三这个商家对它的店铺的某款商品进行了价格的修改。这样在我们这就会记录下一条日志在我们的系统当中，在这个系统中的部分信息我们是可以提供给商家、运营人员看，从而让商家知道自己做了哪些操作，也让运营人员更好的对商家进行管理，除此之外，也可以帮忙查找从log中找不到的信息，从而帮助开发人员解决问题。其他的不多说，接下来就讲一下我们的业务场景。
业务场景
我们有许多的业务系统，如订单、商品，还要一些其他的系统，之前，大家都是各自记录各自的日志，而且记录的方式五花八门，格式也独具一格，而对于商家和运营人员来说这是非常头疼的一件事，没有给运营人员提供一个可以查询日志的平台，每次有问题的时候，只能耗费大半天的时间去找对应的开发团队，请他们配合找出问题所在，而且有的时候效果也不是很好。在这么一种情况下，卖家日志就诞生了，它给商家和运营以及开发提供了一个统一的日志平台，所有团队的日志都可以接入这个平台，通过申请权限，并且运营和商家有问题可以第一时间自己去查找日志解决问题，而不是盲目的找人解决。
日志总体设计
图是这个日志系统总体的整体流程图，在对于处理日志这一块业务上，我们写了一个日志客户端提供给各个组调用，还用到了kafka+Strom的流式计算，对于日志查询这一块，我们首先想到了ES，因为ES是一个分布式的文件检索系统，它可以根据日志的内容提供丰富的检索功能，而对于冷日志的存储，我们用到了一个能够存更大量的工具—HBase，并且也可以根据一些基本的条件进行日志的搜索。
流程：日志客户端 - Kafka集群 - Strom消费 - ES -HBase - ...
技术点
Kafka：Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据，说浅显易懂一点，我们可以将Kafka理解成为一个消息队列。
Storm：Storm是开源的分布式实时大数据处理框架,它是实时的，我们可以将它理解为一个专门用来处理流式实时数据的东西。
ElasticSearch：ES是一个基于Lucene的搜索服务器，它是一个分布式的文件检索系统，它给我们提供了高效的检索，以及支持多种检索条件，用起来也十分方便。
HBase：HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，适用于结构化的存储，底层依赖于Hadoop的HDFS，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。
日志客户端
日志客户端给各个系统提供了一个统一的Api,就类似于Log4j这些日志工具一样，这样使得接入变得方便简洁，就和平常写日志没什么区别。这里需要提到的一个点是客户端对于日志的处理过程，下面我用图来给大家进行说明，如下图：
大家可能会疑惑，为什么不直接写Kafka呢？那么接下来我给大家做个比较，直接写入本地快，还是写Kafka快呢？很明显，写入本地快。因为写日志，我们想达到的效果是尽量不要影响业务，能够以更快的方式处理的就用更快的方式处理，而对于日志后期的处理，我们只需要在后台开启固定的几个线程就可以了，这样既使的业务对此无感知，又不浪费资源，除此之外，落盘的方式还为日志数据不丢提供了保障。
此外，这里本地数据的落盘和读取都用到了Nio的内存映射，写入和读取的数据又有了进一步的提升，使得我们的业务日志快速落盘，并且能够快速的读取出来发送到Kafka。这也是这一块的优势。
为什么要用Kafka
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
