5月安卓手機好評榜：魅族20 Pro奪冠
性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數據來源安兔兔評測，收集時間2023年5月1日至5月31日，僅限國內市場。第一名：魅族20 Pro好評率：97.50%不得不感慨魅族老品牌還
可能大家會想，現在各種編程語言里面都有著各種各樣的日志處理函數，比如Java里面不僅僅可以通過System.out.print()方法打印日志，還有log4j等更為成熟的專業日志包可以進行調用;不僅僅Java，PHP、Golang、Python等當前互聯網行業用的比較多的編程語言都提供了成熟的日志方法類或者日志包，甚至上古編程語言C++也提供了簡易的日志方法。那么讀者朋友們有興趣知道類似log4j這樣的日志包其底層到底是如何構建高效率的日志處理方法嗎?亦或是未來遇到了這些日志包已經無法滿足需求了，必須要自己寫高度定制化日志服務才能較好地處理等場景的時候。俗話說，技多不壓身，接下來，本文將從0開始探討和分析如何寫一個高可用的日志包。
通常來說，軟件應用的日志分為兩個部分：前端部分以及后端部分，其中針對前端部分主要是開發者的應用程序通過程序邏輯構造需要打印的日志內容，再通過調用日志打印方法進行日志的打印。而后端則是像背后看不見的英雄一樣，主要負責把這些內容實實在在地寫到既定的地方。
這樣的分工讓我們不自覺地便能套用上“生產者-消費者”數據模型。這種模型想必只要是計算機圈子的同學都不會陌生：各種經典的數據隊列應用如kafka、RocketMQ等，其中的用戶手冊中第一章必然會說說“生產者”和“消費者”兩者的關系。那么套用到本文日志模型里面，前端部分作為構建日志內容并調用日志方法的模塊，則能套用上“生產者”這一概念，而后端真正的日志處理部分則套用上“消費者”這一概念。
圖片
圖1 生產者和消費者關系圖
通常來講，計算機世界絕大多數應用都采用了多線程處理的方式，以此來高效率地服務計算機使用者們，多線程就類似于買賣東西的窗口，多一個窗口就能在同一時間多服務一個客戶。我們先假設這些服務窗口都屬于上個世紀的形態，未進行信息化升級，所有的服務流水、服務內容等都記錄在紙上，那么窗口管理人員怎么來匯總這些信息呢?這個倒不是什么難題，聰明的讀者們也一定能想到：在下班后統一收集放在一起就可以了。如果要保證時間順序呢?也不難，按所有窗口紙張上記錄的服務時間排序再謄抄一份就可以了。那么終極問題來了，如果還要保證實時性呢?那要不再加派一人，只要某個窗口完成了客人的服務，則馬上去該窗口收集實時的信息，然后交給后面的人立即謄抄匯總。
而本質上多線程的日志問題和窗口信息傳遞問題基本一致，日志最終是落入計算機磁盤存儲，而日志所對應的文件則屬于進程獨占模式——同一個文件只能在一個時間里被一個進程使用，如果不設成進程獨占的方式，可以對應想象上一段落所說的窗口匯總表，如果多個謄抄人同時在那張紙上寫來寫去會怎樣?
圖片
圖2 多線程日志整體關系圖
多線程并發的目標是提升整體性能，但是應用程序采用了多線程的方式則會相應地引入線程間上下文切換、內存同步、賢臣阻塞等問題。而簡單處理這種問題的方式則是對線程進行加鎖。其實在很多時候，并發編程提升性能優化應用能力方面主要就是圍繞如何優化線程的鎖，一些方法論主要講述如何縮小鎖的范圍、減少鎖的粒度、鎖分段、避免熱點區域加串行鎖等進行展開，圍繞這些方法論也誕生了讀寫鎖、分段鎖等方法。單獨針對日志文件采用讀寫鎖是比較合理的手段，即只在寫入的時候對文件進行加鎖，讀取的時候所有應用都可以任意讀取文件獲取內容，這樣既保證了寫入文件內容的原子性也保證了其他業務能獲取日志的實時性。
解決了文件讀取的問題，那么在寫入日志文件的時候直接粗暴地加鎖會不會對整個應用的性能造成重大影響呢?答案是肯定的，這樣做的結果就是整個應用性能瓶頸都集中到了計算機磁盤性能上，很顯然，計算機的磁盤性能可不咋地。針對此，在日志包的設計上又想到了“生產者-消費者”模型中的數據通道，簡單來說，這塊主要通過緩沖區來實現，在常用的日志包設計上，多數都采用“雙緩沖區”的方式作為日志包的核心。
經過以上梳理，整個日志包在設計思路上變得清晰了起來，即：
1) 在內存中創建兩個緩沖區，緩沖區大小視日志量和頻率大小而定，通常取4k左右。
2) 當前端模塊往第一塊緩沖區寫入內容時，后端模塊則將第二塊緩沖區的內容寫入到文件。
3) 當第一塊緩沖區寫滿時，則交換順序，前端往第二塊緩沖區寫入內容，而后端則將第一塊緩沖區內容寫入到文件。
圖片
圖3 前臺模塊寫入第一塊緩沖區，后臺模塊將第二塊緩沖區內容寫入到文件
圖片
圖4 前臺模塊寫入第二塊緩沖區，后臺模塊將第一塊緩沖區內容寫入到文件
當然，僅僅這樣還不足以作為成熟而高效的日志包，在緩沖區的設計上還需考慮寫入文件的實時性，即當緩沖區一直寫不滿時需在固定的時間進行緩沖區的強制切換，以保證日志文件中能讀取到較為實時的日志內容。
在一些日志文件處理細節問題上，如程序突然退出時截獲系統信號，盡可能將剩余日志內容寫入到文件以便后續跟蹤問題等;在不借助第三方工具狀態下，使用兩級文件指針的方式，保證按固定時間分割的日志不會出現日志消失等情況。
在日志包對外暴露的方法上，同大多數日志包一樣，提供分級的日志打印方式，并設計模板變量以支持任意格式的日志內容，同時還提供輸出格式方法以及日志文件分割方法以便進行便利的日志包配置。
在綜合考慮這些問題后，整個流程如下：
圖片
圖5 整體流程圖
以上便是日志包的主要設計思路，從這樣的設計思路中我們可以看到，整個設計上主要就是如何對抗以下兩個核心問題：
第一個是應程序中多線程的資源搶占問題，第二個便是計算機磁盤的低效率問題。
該日志包已經在移動OneNET公有云平臺、城市物聯網平臺等平臺里面發光發熱，體量最大的公有云平臺日均處理日志量已超過4億條。當然，在日志包這一模塊過后，如果還需補充完整整個日志系統，后續的日志采集、日志落庫、日志分析等又是一個有一個新的技術探索領域。
本文鏈接：http://www.www897cc.com/showinfo-26-13641-0.html從0手寫一個多線程日志包
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 8000字+22張圖探秘SpringCloud配置中心的核心原理
下一篇： 客服發送一條消息背后的技術和思考
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號