9 构建流式计算卖家日志系统应用实践.docxVIP

构建流式计算卖家日志系统应用实践 2021-09-21 引言 本文给大家叙述的是我们如何去构建一个日志系统，用到了那些技术，为什么用这些技术，并且叙述了遇到的问题及优化的过程，期望给大家在实践中能够供应一些参考。 最近在维护一个有关于日志的项目，这个项目是担任收集、处理、存储、查询京东卖家相关操作的日志，我们这里就叫它“卖家日志”。在日常的开发过程中，可能我们对日志这个词并不生疏，例如我们常接触到的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 首先给大家引见一下Kafka，其实网上也有很多的例子，接下来我说一下我对Kafka的理解吧，有不对的地方还请大家准时指正。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的全部动作流数据，说浅显易懂一点，我们可以将Kafka理解成为一个消息队列。具体的一些细节，大家可以上网搜索。 Kafka次要应用场景中： 持续的消息：为了从大数据中派生出有用的数据，任何数据的丢失都会影响生成的结果，Kafka供应了一个简单度为O(1)的磁盘结构存储数据，