由法迪·奧貝德,首席工程師和技術主管,廣告產品

如果您處理過或即時處理過,則可能需要處理事件日誌記錄。在 ShareThis ,我們全都了解即時性 – 我們在社交信號發生時收集,將業務邏輯應用於這些信號,最後將這些信號轉換為複雜的廣告定位規則。 

在本帖子中,我們將介紹規模方面的事件日誌記錄。 簡化的管道版本如下所示:

卡夫卡河每天輸送約8億至10億次事件。每個事件平均擴展到 12 個虛擬事件,因此 Kafka 消費者群集中的業務邏輯必須每天處理和評估 9-120 億個事件,並將符合條件的事件記錄到磁碟。

最初,我們有原始事件到虛擬事件的 1......映射,這沒什麼大不了的,因為我們有"足夠的計算機"。 群集容量為 3 c3.x large 實例,由自產同步記錄器支援。

隨著時間的推移,映射從 1×1 增加到 1...(1)、3等。群集中的每個 Kafka 框都運行了 25 個線程,在載入時,鎖定寫入操作的效果(如此代碼段所示)已使該寫入操作嚴重。線程池執行器在服務傳入請求的能力方面落後,Kafka 偏移開始滯後,有時甚至無法趕上。

正在運行的線程的配置檔顯示,線程幾乎一直被阻止,yikes!

我們開始研究我們的選擇。我們的清單是: 

• 新增更多電腦
• 國產同步記錄器
• Log4j2 非同步 + 干擾器 + 隨機存取檔案

我們經歷了利弊,降落在Log4j2上。我們把它作為基準,結果令人印象深刻。為了本文的目的,我們顯示了兩個圖表:第一個圖表顯示低負載的輸送量,第二個顯示高負載的輸送量。 不錯的部分是,它是多麼容易連接到現有的項目,支援和充足的檔。

總之,我們可以有把握地說,我們的"log4j2異步 + 干擾器 + 隨機訪問檔"的日誌記錄選擇是正確的。如果您正在經歷類似的過程,我們強烈建議分析您的應用程序,佈局您的選項,並測試它。