Part 01 引言
可能大家會(huì)想，現(xiàn)在各種編程語言里面都有著各種各樣的日志處理函數(shù)，比如JAVA里面不僅僅可以通過System.out.print()方法打印日志，還有l(wèi)og4j等更為成熟的專業(yè)日志包可以進(jìn)行調(diào)用;不僅僅Java，php、Golang、Python/ target=_blank class=infotextkey>Python等當(dāng)前互聯(lián)網(wǎng)行業(yè)用的比較多的編程語言都提供了成熟的日志方法類或者日志包，甚至上古編程語言C++也提供了簡易的日志方法。那么讀者朋友們有興趣知道類似log4j這樣的日志包其底層到底是如何構(gòu)建高效率的日志處理方法嗎?亦或是未來遇到了這些日志包已經(jīng)無法滿足需求了，必須要自己寫高度定制化日志服務(wù)才能較好地處理等場(chǎng)景的時(shí)候。俗話說，技多不壓身，接下來，本文將從0開始探討和分析如何寫一個(gè)高可用的日志包。
Part 02 模型概述
通常來說，軟件應(yīng)用的日志分為兩個(gè)部分：前端部分以及后端部分，其中針對(duì)前端部分主要是開發(fā)者的應(yīng)用程序通過程序邏輯構(gòu)造需要打印的日志內(nèi)容，再通過調(diào)用日志打印方法進(jìn)行日志的打印。而后端則是像背后看不見的英雄一樣，主要負(fù)責(zé)把這些內(nèi)容實(shí)實(shí)在在地寫到既定的地方。
這樣的分工讓我們不自覺地便能套用上“生產(chǎn)者-消費(fèi)者”數(shù)據(jù)模型。這種模型想必只要是計(jì)算機(jī)圈子的同學(xué)都不會(huì)陌生：各種經(jīng)典的數(shù)據(jù)隊(duì)列應(yīng)用如kafka、RocketMQ等，其中的用戶手冊(cè)中第一章必然會(huì)說說“生產(chǎn)者”和“消費(fèi)者”兩者的關(guān)系。那么套用到本文日志模型里面，前端部分作為構(gòu)建日志內(nèi)容并調(diào)用日志方法的模塊，則能套用上“生產(chǎn)者”這一概念，而后端真正的日志處理部分則套用上“消費(fèi)者”這一概念。
圖片
圖1 生產(chǎn)者和消費(fèi)者關(guān)系圖
Part 03 問題分析
通常來講，計(jì)算機(jī)世界絕大多數(shù)應(yīng)用都采用了多線程處理的方式，以此來高效率地服務(wù)計(jì)算機(jī)使用者們，多線程就類似于買賣東西的窗口，多一個(gè)窗口就能在同一時(shí)間多服務(wù)一個(gè)客戶。我們先假設(shè)這些服務(wù)窗口都屬于上個(gè)世紀(jì)的形態(tài)，未進(jìn)行信息化升級(jí)，所有的服務(wù)流水、服務(wù)內(nèi)容等都記錄在紙上，那么窗口管理人員怎么來匯總這些信息呢?這個(gè)倒不是什么難題，聰明的讀者們也一定能想到：在下班后統(tǒng)一收集放在一起就可以了。如果要保證時(shí)間順序呢?也不難，按所有窗口紙張上記錄的服務(wù)時(shí)間排序再謄抄一份就可以了。那么終極問題來了，如果還要保證實(shí)時(shí)性呢?那要不再加派一人，只要某個(gè)窗口完成了客人的服務(wù)，則馬上去該窗口收集實(shí)時(shí)的信息，然后交給后面的人立即謄抄匯總。
而本質(zhì)上多線程的日志問題和窗口信息傳遞問題基本一致，日志最終是落入計(jì)算機(jī)磁盤存儲(chǔ)，而日志所對(duì)應(yīng)的文件則屬于進(jìn)程獨(dú)占模式——同一個(gè)文件只能在一個(gè)時(shí)間里被一個(gè)進(jìn)程使用，如果不設(shè)成進(jìn)程獨(dú)占的方式，可以對(duì)應(yīng)想象上一段落所說的窗口匯總表，如果多個(gè)謄抄人同時(shí)在那張紙上寫來寫去會(huì)怎樣?
圖片
圖2 多線程日志整體關(guān)系圖
Part 04 日志包設(shè)計(jì)
多線程并發(fā)的目標(biāo)是提升整體性能，但是應(yīng)用程序采用了多線程的方式則會(huì)相應(yīng)地引入線程間上下文切換、內(nèi)存同步、賢臣阻塞等問題。而簡單處理這種問題的方式則是對(duì)線程進(jìn)行加鎖。其實(shí)在很多時(shí)候，并發(fā)編程提升性能優(yōu)化應(yīng)用能力方面主要就是圍繞如何優(yōu)化線程的鎖，一些方法論主要講述如何縮小鎖的范圍、減少鎖的粒度、鎖分段、避免熱點(diǎn)區(qū)域加串行鎖等進(jìn)行展開，圍繞這些方法論也誕生了讀寫鎖、分段鎖等方法。單獨(dú)針對(duì)日志文件采用讀寫鎖是比較合理的手段，即只在寫入的時(shí)候?qū)ξ募M(jìn)行加鎖，讀取的時(shí)候所有應(yīng)用都可以任意讀取文件獲取內(nèi)容，這樣既保證了寫入文件內(nèi)容的原子性也保證了其他業(yè)務(wù)能獲取日志的實(shí)時(shí)性。
解決了文件讀取的問題，那么在寫入日志文件的時(shí)候直接粗暴地加鎖會(huì)不會(huì)對(duì)整個(gè)應(yīng)用的性能造成重大影響呢?答案是肯定的，這樣做的結(jié)果就是整個(gè)應(yīng)用性能瓶頸都集中到了計(jì)算機(jī)磁盤性能上，很顯然，計(jì)算機(jī)的磁盤性能可不咋地。針對(duì)此，在日志包的設(shè)計(jì)上又想到了“生產(chǎn)者-消費(fèi)者”模型中的數(shù)據(jù)通道，簡單來說，這塊主要通過緩沖區(qū)來實(shí)現(xiàn)，在常用的日志包設(shè)計(jì)上，多數(shù)都采用“雙緩沖區(qū)”的方式作為日志包的核心。
經(jīng)過以上梳理，整個(gè)日志包在設(shè)計(jì)思路上變得清晰了起來，即：
1) 在內(nèi)存中創(chuàng)建兩個(gè)緩沖區(qū)，緩沖區(qū)大小視日志量和頻率大小而定，通常取4k左右。
2) 當(dāng)前端模塊往第一塊緩沖區(qū)寫入內(nèi)容時(shí)，后端模塊則將第二塊緩沖區(qū)的內(nèi)容寫入到文件。
3) 當(dāng)?shù)谝粔K緩沖區(qū)寫滿時(shí)，則交換順序，前端往第二塊緩沖區(qū)寫入內(nèi)容，而后端則將第一塊緩沖區(qū)內(nèi)容寫入到文件。
圖片
圖3 前臺(tái)模塊寫入第一塊緩沖區(qū)，后臺(tái)模塊將第二塊緩沖區(qū)內(nèi)容寫入到文件
圖片
圖4 前臺(tái)模塊寫入第二塊緩沖區(qū)，后臺(tái)模塊將第一塊緩沖區(qū)內(nèi)容寫入到文件
當(dāng)然，僅僅這樣還不足以作為成熟而高效的日志包，在緩沖區(qū)的設(shè)計(jì)上還需考慮寫入文件的實(shí)時(shí)性，即當(dāng)緩沖區(qū)一直寫不滿時(shí)需在固定的時(shí)間進(jìn)行緩沖區(qū)的強(qiáng)制切換，以保證日志文件中能讀取到較為實(shí)時(shí)的日志內(nèi)容。
在一些日志文件處理細(xì)節(jié)問題上，如程序突然退出時(shí)截獲系統(tǒng)信號(hào)，盡可能將剩余日志內(nèi)容寫入到文件以便后續(xù)跟蹤問題等;在不借助第三方工具狀態(tài)下，使用兩級(jí)文件指針的方式，保證按固定時(shí)間分割的日志不會(huì)出現(xiàn)日志消失等情況。
在日志包對(duì)外暴露的方法上，同大多數(shù)日志包一樣，提供分級(jí)的日志打印方式，并設(shè)計(jì)模板變量以支持任意格式的日志內(nèi)容，同時(shí)還提供輸出格式方法以及日志文件分割方法以便進(jìn)行便利的日志包配置。
在綜合考慮這些問題后，整個(gè)流程如下：
圖片
圖5 整體流程圖
Part 05 總結(jié)
以上便是日志包的主要設(shè)計(jì)思路，從這樣的設(shè)計(jì)思路中我們可以看到，整個(gè)設(shè)計(jì)上主要就是如何對(duì)抗以下兩個(gè)核心問題：
第一個(gè)是應(yīng)程序中多線程的資源搶占問題，第二個(gè)便是計(jì)算機(jī)磁盤的低效率問題。
該日志包已經(jīng)在移動(dòng)On.NET公有云平臺(tái)、城市物聯(lián)網(wǎng)平臺(tái)等平臺(tái)里面發(fā)光發(fā)熱，體量最大的公有云平臺(tái)日均處理日志量已超過4億條。當(dāng)然，在日志包這一模塊過后，如果還需補(bǔ)充完整整個(gè)日志系統(tǒng)，后續(xù)的日志采集、日志落庫、日志分析等又是一個(gè)有一個(gè)新的技術(shù)探索領(lǐng)域。
