總覽

我正在看Typesafe的Rolan Kuhn在介紹反應流方面的出色演講，乍一看似乎與《紀事報》有一些相似的目標，但是當您深入研究細節時，對我來說顯然有一些關鍵假設是根本不同。

關鍵假設

《紀事》設計的主要假設是

• 低延遲是您的問題，而不是吞吐量。 數據來自微突發，您希望在下一次微突發活動之前盡快處理。
• 如果您忙碌，則不能暫停交流/制作人。 （或暫停最終用戶不是一種選擇）
• 您的信息具有很高的價值，記錄每個事件的詳細時間非常有價值。 記錄所有事件是了解微爆的關鍵。
• 您希望能夠檢查過去發生的任何事件。

低延遲至關重要

紀事報旨在幫助您解決的關鍵問題是一致的低延遲。 它假定如果延遲足夠低，那么吞吐量就不會有問題。 許多基于Web的系統都是為吞吐量而設計的，只要最終用戶看不到延遲，延遲就不會成為問題。 對于軟實時系統，大多數時候您都需要低延遲，而最壞情況下的延遲則要適度，這要比人類看到的快得多。

你無法阻止世界

另一個關鍵假設是流量控制不是一種選擇。 如果您運行緩慢，則無法對交易所及其所有用戶說，請等我一會兒再追。 這意味著生產者永遠不會被消費者放慢腳步。 降低生產者速度實際上與增加延遲時間相同，但是此延遲時間很容易隱藏。 如果您等到生產者將事件標記為時間戳，則可以使延遲看起來更好。 如果您想采取更現實的措施，則應使用時間戳記，事件應該由生產者發送 ，并且不會延遲。

您需要記錄所有內容以便重播

重放對于在一定條件下測試應用程序很有用。 例如，您可以更改您的應用程序，不僅可以看到它的行為正確，而且可以及時運行。 對于定量分析，他們將需要一組數據來調整其策略。

實時重播舊事件。

您不必記住以后要引用的事件副本，而可以記住它的索引，并可以按需稍后重播該事件。 這樣可以節省堆中的內存，或僅在情況下復制數據。

微爆發對于理解您的系統至關重要。

一些系統的性能以每天的交易為特征。 這意味著，如果在前23個小時內沒有完成任何事務，而所有事務都在最后一個小時內完成，那么您仍將每天執行這么多事務。 經常引用每天的交易是因為它的數量更高，但就我而言，整天簡化工作量聽起來很奢侈。 某些系統可能以每秒的事務數為特征。 這可能意味著這些事務可以在一秒鐘內開始并完成，但并非總是如此。 如果您有1000筆交易，并且每毫秒進行一次交易，那么您將獲得均勻的響應時間。 我發現更有趣的是一天中最忙的一秒鐘的交易數量。 這樣可以指示系統應該能夠處理的流速。

檢查微脈沖

考慮一個系統，該系統在相同的100微秒內獲得30個事件，而這些突發間隔為100毫秒。 這可能顯示為每秒（30 / 0.1）300個事務，這聽起來相對容易，如果我們需要做的只是跟上進度，但是如果我們希望盡快做出響應，則短期/突發吞吐量為100中的30微秒或每秒30萬個事件。 換句話說，要盡可能快地處理微爆發，您將需要一個系統，該系統能夠處理的吞吐量比您在幾秒鐘，幾分鐘或一天內預期的吞吐量高出多個數量級。 理想情況下，系統的吞吐量將是一天中最忙的一秒鐘的100倍。 在不減慢對這些數據突發的處理速度的情況下，每秒處理最繁忙的10毫秒所需的時間。

編年史如何改善微爆的處理

低垃圾率

最小化垃圾是避免GC暫停的關鍵。 為了有效地使用L1和L2緩存，您需要將垃圾率保持在非常低的水平。 如果您沒有有效地使用這些緩存，則您的應用程序速度可能會慢2-5倍。 Chronicle中的垃圾非常低，您可以處理一百萬個事件，而jstat不會檢測到您創建了任何垃圾。 jstat僅在分配了新的TLAB時顯示4 KB的倍數。 編年史確實會產生垃圾，但是它非常低。 即每百萬個事件過程中有幾個對象。 一旦使GC暫停易于管理或不存在，您便開始看到系統中的其他延遲源。 拿走巨石，您開始看到巖石。 拿走巖石，您開始看到鵝卵石。

支持全部寫入模型。

眾所周知，如果保持DEBUG級別登錄，則會大大降低應用程序的速度。 在記錄您以后可能想要知道的一切與對您的應用程序的影響之間存在緊張關系。 編年史設計得足夠快，您可以記錄所有內容。 如果替換系統中的隊列和IPC連接，則可以提高性能，并且可以免費甚至更好地“記錄所有內容”。 能夠記錄所有內容意味著您可以在系統的每個階段添加跟蹤時間，然后監視系統，還可以深入研究系統中最糟糕的1％延遲。 這不是您可以使用剖析器為您提供平均值的方法。 通過編年史，您可以回答以下問題： 系統的哪些部分負責一天中最慢的20個事件？

記事本與操作系統的交互最少。

系統調用速度很慢，如果可以避免調用操作系統，則可以節省大量的延遲。 例如，如果在回送時通過TCP發送消息，則在寫入和讀取數據之間可能會增加10微秒的延遲。 您可以寫入編年史，這是對內存的簡單寫操作，也可以從編年史中讀取，這也是從內存中讀取的內容，延遲為0.2微秒。 （正如我之前提到的，您也將獲得持久性）

無需擔心用完堆。

無限制隊列的一個常見問題，這使用了一個開放式堆。 Chronicle通過不使用堆來存儲數據，而是使用內存映射文件來解決此問題。 通過使數據更緊湊，可以提高內存利用率，但也意味著1 GB的JVM一天可以流1 TB的數據，而不必擔心堆或您擁有多少主內存。 在這種情況下，無界隊列變得更易于管理。

結論

通過基于不同的假設，Chronicle解決了其他解決方案避免的問題，例如需要流控制或使用消息（刪除已處理消息）。 Chronicle旨在更有效地利用您的硬件，因此您不需要說30個服務器的云即可每秒處理約一百萬個事件（如許多基于云的解決方案所稱），您可以與開發人員聯系以達到此事件率筆記本電腦。

翻譯自: https://www.javacodegeeks.com/2014/05/chronicle-and-low-latency-in-java.html

總結

以上是生活随笔為你收集整理的Java的编年史和低延迟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。