你徹底沒了解過的日誌異步落庫

前言

在互聯網設計架構過程當中,日誌異步落庫,儼然已是高併發環節中不可缺乏的一環。爲何說是高併發環節中不可缺乏的呢? 緣由在於,若是直接用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策略,當大量數據過來,緩衝區滿了以後,會拋棄部分數據。此種方案適用於可以容忍數據丟失的業務場景,不適用於對數據完整有嚴格要求的業務場景。併發

來看看具體的實現方式:app

首先,咱們須要自定義一個Appender,繼承自log4j的AppenderSkeleton類,實現方式以下:dom

clipboard.png

而後在log4j.xml中,爲此類進行配置:異步

clipboard.png

最後就能夠按照以下的方式進行正常使用了:分佈式

clipboard.png

注意: 此處須要注意log4j的一個性能問題。在log4j的conversionPattern中,匹配符最好不要出現 C% L%通配符,壓測實踐代表,這兩個通配符會致使log4j打日誌的效率下降10倍。微服務

方案一很簡便,且剝離了接口直接依賴mq致使的性能問題。可是沒法解決數據丟失的問題(可是咱們其實能夠在本地搞個策略落盤來不及處理的數據,能夠大大的減小數據丟失的概率)。可是不少的業務場景,是須要數據不丟失的,因此這就衍生出咱們的另外一套方案來。高併發

方案二:增量消費log4j日誌

此種方式,是開啓worker在後臺增量消費log4j的日誌信息,和接口徹底脫離。此種方式相比方案一,能夠保證數據的不丟失,且能夠作到徹底不影響接口的ops。可是此種方式,因爲是後臺worker在後臺啓動進行掃描,會致使落庫的數據慢一些,好比一分鐘以後才落庫完畢。因此適用於對落庫數據實時性不高的場景。

具體的實現步驟以下:

首先,將須要進行增量消費的日誌統一打到一個文件夾,以天爲單位,天天生成一個帶時間戳日誌文件。因爲log4j不支持直接帶時間戳的日誌文件生成,因此這裏須要引入log4j.extras組件,而後配置log4j.xml以下:

clipboard.png

以後在代碼中的申明方式以下:

clipboard.png

最後在須要記錄日誌的地方使用方式以下:

clipboard.png

這樣就能夠將日誌打印到一個單獨的文件中,且按照日期,天天生成一個。

而後,當日志文件生成完畢後,咱們就能夠開啓咱們的worker進行增量消費了,這裏的增量消費方式,咱們選擇RandomAccessFile這個類來進行,因爲其獨特的位點讀取方式,可使得咱們很是方便的根據位點的位置來消費增量文件,從而避免了逐行讀取這種低效率的實現方式。

注意,爲每一個日誌文件都單首創建了一個位點文件,裏面存儲了對應的文件的位點讀取信息。當worker掃描開始的時候,會首先讀取位點文件裏面的位點信息,而後找到相應的日誌文件,從位點信息位置開始進行消費。這就是整個增量消費worker的核心。具體代碼實現以下(代碼太長,作了摺疊):

  • View Code

此種方式因爲worker掃描是每隔一段時間啓動一次進行消費,因此致使數據從產生到入庫,可能經歷時間超過一分鐘以上,可是在一些對數據延遲要求比較高的業務場景,好比庫存扣減,是不能容忍的,因此這裏咱們就引伸出第三種作法,基於內存文件隊列的異步日誌消費。

方案三:基於內存文件隊列的異步日誌消費

因爲方案一和方案二都嚴重依賴log4j,且方案自己都存在着要麼丟數據,要麼入庫時間長的缺點,因此都並非那麼盡如人意。可是本方案的作法,既解決了數據丟失的問題,又解決了數據入庫時間被拉長的尷尬,因此是終極解決之道。並且在大促銷過程當中,此種方式經歷了實戰檢驗,能夠大面積的推廣使用。

此方案中提到的內存文件隊列,是我司自研的一款基於RandomAccessFile和MappedByteBuffer實現的內存文件隊列。隊列核心使用了ArrayBlockingQueue,並提供了produce方法,進行數據入管道操做,提供了consume方法,進行數據出管道操做。並且後臺有一個worker一直啓動着,每隔5ms或者遍歷了100條數據以後,就將數據落盤一次,以防數據丟失。具體的設計,就這麼多,感興趣的能夠根據我提供的信息,本身實踐一下。

因爲有此中間件的加持,數據生產的時候,只須要入壓入管道,而後消費端進行消費便可。未被消費的數據,會進行落盤操做,謹防數據丟失。當大促的時候,大量數據涌來的時候,管道滿了的狀況下會阻塞接口,數據不會被拋棄。雖然可能會致使接口在那一瞬間無響應,可是因爲有落盤操做和消費操做(此操做操控的是JVM堆外內存數據,不受GC的影響,因此不會出現操做暫停的狀況,爲何呢?由於用了MappedByteBuffer),此種阻塞並未影響到接口總體的ops。

在實際使用的時候,ArrayBlockingQueue做爲核心隊列,顯然是全局加鎖的,後續咱們考慮升級爲無鎖隊列,因此將會參考Netty中的有界無鎖隊列:MpscArrayQueue。預計性能將會再好一些。

受限於公司政策,我僅提供大體思路,可是不會提供具體代碼,有問題評論區交流吧。

上面就是在進行異步日誌消費的時候,我所經歷的三個階段,而且一步一步的優化到目前的方式。雖然過程曲折,可是結果使人歡欣鼓舞。若是喜歡就給個推薦,後續我將會持續更新你所不知道的系列,以期達到拋磚引玉的效果。

在此我向你們推薦一個架構學習交流羣。交流學習羣號:478030634 裏面會分享一些資深架構師錄製的視頻錄像:有Spring,MyBatis,Netty源碼分析,高併發、高性能、分佈式、微服務架構的原理,JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源,目前受益良多
圖片描述

你們以爲文章對你仍是有一點點幫助的,你們能夠點擊下方二維碼進行關注。 《Java爛豬皮》 公衆號聊的不只僅是Java技術知識,還有面試等乾貨,後期還有大量架構乾貨。你們一塊兒關注吧!關注爛豬皮,你會了解的更多..............

相關文章
相關標籤/搜索