你完全没了解过的日志异步落库

前言

在互联网设计架构过程中,日志异步落库,俨然已经是高并发环节中不可缺少的一环。为什么说是高并发环节中不可缺少的呢? 原因在于,如果直接用mq进行日志落库的时候,低并发下,生产端生产数据,然后由消费端异步落库,是没有什么问题的,而且性能也都是异常的好,估计tp99应该都在1ms以内。但是一旦并发增长起来,慢慢的你就发现生产端的tp99一直在增长,从1ms,变为2ms,4ms,直至send timeout。尤其在大促的时候,我司的系统就经历过这个情况,当时mq的发送耗时超过200ms,甚至一度有不少timeout产生。

考虑到这种情况在高并发的情况下才出现,所以今天我们就来探索更加可靠的方法来进行异步日志落库,保证所使用的方式不会因为过高的并发而出现接口ops持续下降甚至到不可用的情况。



方案一: 基于log4j的异步appender实现

此种方案,依赖于log4j。在log4j的异步appender中,通过mq进行生产消费入库。相当于在接口和mq之间建立了一个缓冲区,使得接口和mq的依赖分离,从而不让mq的操作影响接口的ops。

此种方案由于使用了异步方式,且由于异步的discard policy策略,当大量数据过来,缓冲区满了之后,会抛弃部分数据。此种方案适用于能够容忍数据丢失的业务场景,不适用于对数据完整有严格要求的业务场景。

来看看具体的实现方式:

首先,我们需要自定义一个Appender,继承自log4j的AppenderSkeleton类,实现方式如下:

public class AsyncJmqAppender extends AppenderSkeleton {

    @Resource(name = "messageProducer")    private MessageProducer messageProducer;

    @Override    protected void append(LoggingEvent loggingEvent) {        asyncPushMessage(loggingEvent.getMessage());    }

    /**     * 异步调用jmq输出日志     * @param message     */    private void asyncPushMessage(Object message) {

        CompletableFuture.runAsync(() -> {

            Message messageConverted = (Message) message;

            try {                messageProducer.send(messageConverted);            } catch (JMQException e) {                e.printStackTrace();            }

        });    }

    @Override    public boolean requiresLayout() {        return false;    }

    @Override    public void close() {

    }}

然后在log4j.xml中,为此类进行配置:

<!--异步JMQ appender--><appender name="async_mq_appender" class="com.jd.limitbuy.common.util.AsyncJmqAppender">    <!-- 设置File参数:日志输出文件名 -->    <param name="File" value="D:/export/Instances/order/server1/logs/order.async.jmq" />    <!-- 设置是否在重新启动服务时,在原有日志的基础添加新日志 -->    <param name="Append" value="true" />    <!-- 设置文件大小 -->    <param name="MaxFileSize" value="10KB" />    <!-- 设置文件备份 -->    <param name="MaxBackupIndex" value="10000" />    <!-- 设置输出文件项目和格式 -->    <layout class="org.apache.log4j.PatternLayout">        <param name="ConversionPattern" value="%m%n" />    </layout></appender><logger name="async_mq_appender_logger">    <appender-ref ref="async_mq_appender"/></logger>

最后就可以按照如下的方式进行正常使用了:

private static Logger logger = LoggerFactory.getLogger("filelog_appender_logger");

注意: 此处需要注意log4j的一个性能问题。在log4j的conversionPattern中,匹配符最好不要出现 C% L%通配符,压测实践表明,这两个通配符会导致log4j打日志的效率降低10倍。

方案一很简便,且剥离了接口直接依赖mq导致的性能问题。但是无法解决数据丢失的问题(但是我们其实可以在本地搞个策略落盘来不及处理的数据,可以大大的减少数据丢失的几率)。但是很多的业务场景,是需要数据不丢失的,所以这就衍生出我们的另一套方案来。



方案二:增量消费log4j日志

此种方式,是开启worker在后台增量消费log4j的日志信息,和接口完全脱离。此种方式相比方案一,可以保证数据的不丢失,且可以做到完全不影响接口的ops。但是此种方式,由于是后台worker在后台启动进行扫描,会导致落库的数据慢一些,比如一分钟之后才落库完毕。所以适用于对落库数据实时性不高的场景。

具体的实现步骤如下:

首先,将需要进行增量消费的日志统一打到一个文件夹,以天为单位,每天生成一个带时间戳日志文件。由于log4j不支持直接带时间戳的日志文件生成,所以这里需要引入log4j.extras组件,然后配置log4j.xml如下:

之后在代码中的申明方式如下:

private static Logger businessLogger = LoggerFactory.getLogger("file_rolling_logger");

最后在需要记录日志的地方使用方式如下:

businessLogger.error(JsonUtils.toJSONString(myMessage))

这样就可以将日志打印到一个单独的文件中,且按照日期,每天生成一个。

然后,当日志文件生成完毕后,我们就可以开启我们的worker进行增量消费了,这里的增量消费方式,我们选择RandomAccessFile这个类来进行,由于其独特的位点读取方式,可以使得我们非常方便的根据位点的位置来消费增量文件,从而避免了逐行读取这种低效率的实现方式。

注意,为每个日志文件都单独创建了一个位点文件,里面存储了对应的文件的位点读取信息。当worker扫描开始的时候,会首先读取位点文件里面的位点信息,然后找到相应的日志文件,从位点信息位置开始进行消费。这就是整个增量消费worker的核心。具体代码实现如下(代码太长,做了折叠):

+

此种方式由于worker扫描是每隔一段时间启动一次进行消费,所以导致数据从产生到入库,可能经历时间超过一分钟以上,但是在一些对数据延迟要求比较高的业务场景,比如库存扣减,是不能容忍的,所以这里我们就引申出第三种做法,基于内存文件队列的异步日志消费。

 方案三:基于内存文件队列的异步日志消费

由于方案一和方案二都严重依赖log4j,且方案本身都存在着要么丢数据,要么入库时间长的缺点,所以都并不是那么尽如人意。但是本方案的做法,既解决了数据丢失的问题,又解决了数据入库时间被拉长的尴尬,所以是终极解决之道。而且在大促销过程中,此种方式经历了实战检验,可以大面积的推广使用。

此方案中提到的内存文件队列,是我司自研的一款基于RandomAccessFile和MappedByteBuffer实现的内存文件队列。队列核心使用了ArrayBlockingQueue,并提供了produce方法,进行数据入管道操作,提供了consume方法,进行数据出管道操作。而且后台有一个worker一直启动着,每隔5ms或者遍历了100条数据之后,就将数据落盘一次,以防数据丢失。具体的设计,就这么多,感兴趣的可以根据我提供的信息,自己实践一下。

由于有此中间件的加持,数据生产的时候,只需要入压入管道,然后消费端进行消费即可。未被消费的数据,会进行落盘操作,谨防数据丢失。当大促的时候,大量数据涌来的时候,管道满了的情况下会阻塞接口,数据不会被抛弃。虽然可能会导致接口在那一瞬间无响应,但是由于有落盘操作和消费操作(此操作操控的是JVM堆外内存数据,不受GC的影响,所以不会出现操作暂停的情况,为什么呢?因为用了MappedByteBuffer),此种阻塞并未影响到接口整体的ops。

在实际使用的时候,ArrayBlockingQueue作为核心队列,显然是全局加锁的,后续我们考虑升级为无锁队列,所以将会参考Netty中的有界无锁队列:MpscArrayQueue。预计性能将会再好一些。

受限于公司政策,我仅提供大致思路,但是不会提供具体代码,有问题评论区交流吧。



上面就是在进行异步日志消费的时候,我所经历的三个阶段,并且一步一步的优化到目前的方式。虽然过程曲折,但是结果令人欢欣鼓舞。如果喜欢就给个推荐,后续我将会持续更新你所不知道的系列,以期达到抛砖引玉的效果。

在此我向大家推荐一个架构学习交流群。交流学习群号:478030634  里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

大家觉得文章对你还是有一点点帮助的,大家可以点击下方二维码进行关注。 《Java烂猪皮》 公众号聊的不仅仅是Java技术知识,还有面试等干货,后期还有大量架构干货。大家一起关注吧!关注烂猪皮,你会了解的更多..............

原文:https://www.cnblogs.com/scy251147/p/9193075.html

原文地址:https://www.cnblogs.com/AIPAOJIAO/p/9545215.html

时间: 2024-10-27 20:03:03

你完全没了解过的日志异步落库的相关文章

你所不知道的日志异步落库

在互联网设计架构过程中,日志异步落库,俨然已经是高并发环节中不可缺少的一环.为什么说是高并发环节中不可缺少的呢? 原因在于,如果直接用mq进行日志落库的时候,低并发下,生产端生产数据,然后由消费端异步落库,是没有什么问题的,而且性能也都是异常的好,估计tp99应该都在1ms以内.但是一旦并发增长起来,慢慢的你就发现生产端的tp99一直在增长,从1ms,变为2ms,4ms,直至send timeout.尤其在大促的时候,我司的系统就经历过这个情况,当时mq的发送耗时超过200ms,甚至一度有不少t

dataguard主库删除归档日志后从库恢复的方法

------------------方法1在主库上使用备份的进行恢复丢失的归档日志-------------------------1.发现主库备份后删除了归档,但是这些归档从库还没应用,也没有传到从库从库应用的最新的归档日志为592SQL> connect / as sysdbaConnected.SQL> Select Max(t.SEQUENCE#) From V$archived_Log t; MAX(T.SEQUENCE#)---------------- 592 主库的归档日志SQ

小白学 Python 爬虫(32):异步请求库 AIOHTTP 基础入门

人生苦短,我用 Python 前文传送门: 小白学 Python 爬虫(1):开篇 小白学 Python 爬虫(2):前置准备(一)基本类库的安装 小白学 Python 爬虫(3):前置准备(二)Linux基础入门 小白学 Python 爬虫(4):前置准备(三)Docker基础入门 小白学 Python 爬虫(5):前置准备(四)数据库基础 小白学 Python 爬虫(6):前置准备(五)爬虫框架的安装 小白学 Python 爬虫(7):HTTP 基础 小白学 Python 爬虫(8):网页基

Java日志信息存库(log4j篇)

一.Log4j简介 在一个完整的J2EE项目开发中,日志是一个非常重要的功能组成部分.它可以记录下系统所产生的所有行为,并按照某种规范表达出来.我们可以通过日志信息为系统进行排错,优化系统的性能,或者根据这些信息调整系统等行为.Log4j是Apache针对于日志信息处理的一个开源项目,其最大特点是通过一个配置文件就可以灵活地控制日志信息的输出方式(控制台.文件和数据库等).日志输出格式及日志信息打印级别等,而不需要修改应用的代码. 二.编写背景 作为一名程序猿在开发中总能遇到一些比较奇葩的需求,

Java日志信息存库(logback篇)

一.Logback简介 Logback是由log4j创始人设计的又一个开源日志组件.logback当前分成三个模块:logback-core,logback- classic和logback-access.logback-core是其它两个模块的基础模块.logback-classic是log4j的一个 改良版本.此外logback-classic完整实现SLF4J API使你可以很方便地更换成其它日志系统如log4j或JDK14 Logging.logback-access访问模块与Servl

mysql慢查询日志进行按库切割重写文件然后分析

需求: 把每天的慢查询日志进行按库切割 对每个库的慢查询日志进行分析 思路: 工具/功能 一般统计信息 高级统计信息 脚本 优势 mysqldumpslow 支持 不支持 perl mysql官方自带 mysqlsla 支持 支持 perl 功能强大,数据报表齐全,定制化能力强. mysql-explain-slow-log 支持 不支持 perl 无 mysql-log-filter 支持 部分支持 python or php 不失功能的前提下,保持输出简洁 myprofi 支持 不支持 ph

log4j日志异步化大幅提升系统性能

.log4j已成为大型系统必不可少的一部分,log4j可以很方便的帮助我们在程序的任何位置输出所要打印的信息,便于我们对系统在调试阶段和正式运行阶段对问题分析和定位.由于日志级别的不同,对系统的性能影响也是有很大的差距,日志级别越高,性能越高. 2.log4j主要分为error,warn,info,debug四个级别,也是使用最多的四种,日志级别从左至右依次增加. 3.log4j对系统性能的影响程度主要体现在以下几方面:      a.日志输出的目的地,输出到控制台的速度比输出到文件系统的速度要

centos 7如何因对日志风暴和保证日志及时落盘

Centos7在出现系统异常的情况下,比如iscsi软件栈出错且有持续IO的情况下,很可能会出现持续大量的日志,就像短时强风暴一样,甚至导致日志丢失. 在调试阶段,这些日志都是需要的,为此需要解决此时出现的log drop.方法是修改/etc/rsyslog.conf,加入下面的几行: $SystemLogRateLimitInterval 0 $SystemLogRateLimitBurst 0 $IMUXSockRateLimitInterval 0 $IMJournalRatelimitI

mysqlbinlog抽取二进制日志中某库某表的日志

1.先使用myqlbinlog命令把整个库的二进制日志抽取出来 mysqlbinlog --database=db_name mysql-bin.xxxxxx > db_name.sql 2.然后使用grep命令把某表的二进制日志过滤出来 grep -B3 -w tb_name db_name.sql > tb_name.sql 注意:如果有多个binlog文件,要依次解析二进制日志文件找出需要的某库,某表的二进制日志.