在线韩剧,中国xxxxxxxx19,伊人热人久久中文字幕

一個高效可拓展的異步C++日志庫：RING LOG，本文分享了了其設計方案與技術原理等內容

導論

同步日志與缺點

傳統的日志也叫同步日志，每次調用一次打印日志API就對應一次系統調用write寫日志文件，在日志產生不頻繁的場景下沒什么問題

可是，如果日志打印很頻繁，同步日志有什么問題？

一方面，大量的日志打印陷入等量的write系統調用，有一定系統開銷
另一方面，使得打印日志的進程附帶了大量同步的磁盤IO，影響性能

那么，如何解決如上的問題？就是

異步日志與隊列實現的缺點

異步日志，按我的理解就是主線程的日志打印接口僅負責生產日志數據（作為日志的生產者），而日志的落地操作留給另一個后臺線程去完成（作為日志的消費者），這是一個典型的生產-消費問題，如此一來會使得：

主線程調用日志打印接口成為非阻塞操作，同步的磁盤IO從主線程中剝離出來，有助于提高性能

對于異步日志，我們很容易借助隊列來一個實現方式：主線程寫日志到隊列，隊列本身使用條件變量、或者管道、eventfd等通知機制，當有數據入隊列就通知消費者線程去消費日志

但是，這樣的異步隊列也有一定的問題：

生產者線程產生N個日志，對應后臺線程就會被通知N次，頻繁日志寫入會造成一定性能開銷
不同隊列實現方式也各有缺點：
用數組實現：空間不足時，隊列內存不易拓展
用鏈表實現：每條消息的生產消費都對應內存的創建銷毀，有一定開銷

好了，可以開始正文了

簡介

RING LOG是一個適用于C++的異步日志，其特點是效率高（實測每秒支持125+萬日志寫入）、易拓展，尤其適用于頻繁寫日志的場景

一句話介紹原理：

使用多個大數組緩沖區作為日志緩沖區，多個大數組緩沖區以雙循環鏈表方式連接，并使用兩個指針p1和p2指向鏈表兩個節點，分別用以生成數據、與消費數據

生產者可以是多線程，共同持有p1來生產數據，消費者是一個后臺線程，持有p2去消費數據

大數組緩沖區 + 雙循環鏈表的設計，使得日志緩沖區相比于隊列有更強大的拓展能力、且避免了大量內存申請釋放，提高了異步日志在海量日志生成下的性能表現

此外，RING LOG還優化了每條日志的UTC格式時間的生成，明顯提高日志性能

具體工作原理

數據結構

Ring Log的緩沖區是若干個cell_buffer以雙向、循環的鏈表組成

cell_buffer是簡單的一段緩沖區，日志追加于此，帶狀態：

FREE：表示還有空間可追加日志
FULL：表示暫時無法追加日志，正在、或即將被持久化到磁盤；

Ring Log有兩個指針：

Producer Ptr：生產者產生的日志向這個指針指向的cell_buffer里追加，寫滿后指針向前移動，指向下一個cell_buffer；Producer Ptr永遠表示當前日志寫入哪個cell_buffer，被多個生產者線程共同持有
Consumer Ptr：消費者把這個指針指向的cell_buffer里的日志持久化到磁盤，完成后執行向前移動，指向下一個cell_buffer；Consumer Ptr永遠表示哪個cell_buffer正要被持久化，僅被一個后臺消費者線程持有

起始時刻，每個cell_buffer狀態均為FREE Producer Ptr與Consumer Ptr指向同一個cell_buffer

整個Ring Log被一個互斥鎖mutex保護

大致原理

消費者

后臺線程（消費者）forever loop：

1.上鎖，檢查當前Consumer Ptr：

如果對應cell_buffer狀態為FULL，釋放鎖，去STEP 4；
否則，以1秒超時時間等待條件變量cond；

2.再次檢查當前Consumer Ptr：

若cell_buffer狀態為FULL，釋放鎖，去STEP 4；
否則，如果cell_buffer無內容，則釋放鎖，回到STEP 1；
如果cell_buffer有內容，將其標記為FULL，同時Producer Ptr前進一位；

3.釋放鎖

4.持久化cell_buffer

5.重新上鎖，將cell_buffer狀態標記為FREE，并清空其內容；Consumer Ptr前進一位；

6.釋放鎖

生產者

1.上鎖，檢查當前Producer Ptr對應cell_buffer狀態：

如果cell_buffer狀態為FREE，且生剩余空間足以寫入本次日志，則追加日志到cell_buffer，去STEP X；

2.如果cell_buffer狀態為FREE但是剩余空間不足了，標記其狀態為FULL，然后進一步探測下一位的next_cell_buffer：

如果next_cell_buffer狀態為FREE，Producer Ptr前進一位，去STEP X；
如果next_cell_buffer狀態為FULL，說明Consumer Ptr = next_cell_buffer，Ring Log緩沖區使用完了；則我們繼續申請一個new_cell_buffer，將其插入到cell_buffer與next_cell_buffer之間，并使得Producer Ptr指向此new_cell_buffer，去STEP X；

3.如果cell_buffer狀態為FULL，說明此時Consumer Ptr = cell_buffer，丟棄日志；

4.釋放鎖，如果本線程將cell_buffer狀態改為FULL則通知條件變量cond

在大量日志產生的場景下，Ring Log有一定的內存拓展能力；實際使用中，為防止Ring Log緩沖區無限拓展，會限制內存總大小，當超過此內存限制時不再申請新cell_buffer而是丟棄日志

圖解各場景

初始時候，Consumer Ptr與Producer Ptr均指向同一個空閑cell_buffer1

然后生產者在1s內寫滿了cell_buffer1，Producer Ptr前進，通知后臺消費者線程持久化

消費者持久化完成，重置cell_buffer1，Consumer Ptr前進一位，發現指向的cell_buffer2未滿，等待

超過一秒后cell_buffer2雖有日志，但依然未滿：消費者將此cell_buffer2標記為FULL強行持久化，并將Producer Ptr前進一位到cell_buffer3

消費者在cell_buffer2的持久化上延遲過大，結果生產者都寫滿cell_buffer3456，已經正在寫cell_buffer1了

生產者寫滿寫cell_buffer1，發現下一位cell_buffer2是FULL，則拓展換沖區，新增new_cell_buffer

UTC時間優化

每條日志往往都需要UTC時間：yyyy-mm-dd hh:mm:ss（PS：Ring Log提供了毫秒級別的精度）

Linux系統下本地UTC時間的獲取需要調用localtime函數獲取年月日時分秒

在localtime調用次數較少時不會出現什么性能問題，但是寫日志是一個大批量的工作，如果每條日志都調用localtime獲取UTC時間，性能無法接受

在實際測試中，對于1億條100字節日志的寫入，未優化locatime函數時 RingLog寫內存耗時245.41s，僅比傳統日志寫磁盤耗時292.58s快將近一分鐘；而在優化locatime函數后，RingLog寫內存耗時79.39s，速度好幾倍提升

策略

為了減少對localtime的調用，使用以下策略

RingLog使用變量_sys_acc_sec記錄寫上一條日志時，系統經過的秒數（從1970年起算）、使用變量_sys_acc_min記錄寫上一條日志時，系統經過的分鐘數，并緩存寫上一條日志時的年月日時分秒year、mon、day、hour、min、sec，并緩存UTC日志格式字符串

每當準備寫一條日志：

調用gettimeofday獲取系統經過的秒tv.tv_sec，與_sys_acc_sec比較；
如果tv.tv_sec 與 _sys_acc_sec相等，說明此日志與上一條日志在同一秒內產生，故年月日時分秒是一樣的，直接使用緩存即可；
否則，說明此日志與上一條日志不在同一秒內產生，繼續檢查：tv.tv_sec/60即系統經過的分鐘數與_sys_acc_min比較；
如果tv.tv_sec/60與_sys_acc_min相等，說明此日志與上一條日志在同一分鐘內產生，故年月日時分是一樣的，年月日時分使用緩存即可，而秒sec = tv.tv_sec%60，更新緩存的秒sec，重組UTC日志格式字符串的秒部分；
否則，說明此日志與上一條日志不在同一分鐘內產生，調用localtime重新獲取UTC時間，并更新緩存的年月日時分秒，重組UTC日志格式字符串