it編年史

總覽

我正在看Typesafe的Rolan Kuhn在介紹React流方面的精彩演講，乍一看似乎與《紀(jì)事報(bào)》有一些相似的目標(biāo)，但是當(dāng)您深入研究細(xì)節(jié)時(shí)，很明顯我有一些關(guān)鍵的假設(shè)根本不同。

關(guān)鍵假設(shè)

《紀(jì)事》設(shè)計(jì)的主要假設(shè)是

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

低延遲至關(guān)重要

紀(jì)事報(bào)旨在幫助您解決的關(guān)鍵問題是一致的低延遲。 它假設(shè)如果延遲足夠低，那么吞吐量就不會(huì)有問題。 許多基于Web的系統(tǒng)都是為吞吐量而設(shè)計(jì)的，只要最終用戶看不到延遲，延遲就不會(huì)成為問題。 對(duì)于軟實(shí)時(shí)系統(tǒng)，大多數(shù)時(shí)候您都需要低延遲，而最壞情況下的延遲則要適中，這要比人類看到的要快得多。

你無(wú)法阻止世界

另一個(gè)關(guān)鍵假設(shè)是流量控制不是一種選擇。 如果您運(yùn)行緩慢，則無(wú)法對(duì)交易所及其所有用戶說，請(qǐng)等我一會(huì)兒再等。 這意味著生產(chǎn)者永遠(yuǎn)不會(huì)被消費(fèi)者放慢腳步。 降低生產(chǎn)者速度實(shí)際上與增加延遲時(shí)間相同，但是此延遲時(shí)間很容易隱藏。 如果您等到生產(chǎn)者為事件加上時(shí)間戳記，這會(huì)使您的延遲看起來(lái)更好。 如果您想采取更現(xiàn)實(shí)的措施，則應(yīng)使用時(shí)間戳記，事件應(yīng)該由生產(chǎn)者發(fā)送 ，并且不會(huì)延遲。

您需要記錄所有內(nèi)容以便重播

重放對(duì)于在一定條件下測(cè)試應(yīng)用程序很有用。 例如，您可以更改您的應(yīng)用程序，不僅可以看到它的行為正確，而且可以及時(shí)運(yùn)行。 對(duì)于定量分析，他們將需要一組數(shù)據(jù)來(lái)調(diào)整其策略。

實(shí)時(shí)重播舊事件。

您可以記住它的索引，而不用復(fù)制事件的副本，而稍后可以參考該事件，您可以稍后重播該事件。 這樣可以節(jié)省堆中的內(nèi)存，或僅在情況下復(fù)制數(shù)據(jù)。

微爆發(fā)對(duì)于理解系統(tǒng)至關(guān)重要。

一些系統(tǒng)的性能以每天的交易為特征。 這意味著，如果在前23個(gè)小時(shí)內(nèi)沒有完成任何事務(wù)，而所有事務(wù)都在最后一個(gè)小時(shí)內(nèi)完成，那么您仍將每天執(zhí)行這么多事務(wù)。 經(jīng)常引用每天的交易是因?yàn)樗臄?shù)量更高，但就我而言，整天簡(jiǎn)化工作量聽起來(lái)很奢侈。 某些系統(tǒng)可能以每秒的事務(wù)數(shù)為特征。 這可能意味著這些事務(wù)可以在一秒鐘內(nèi)開始并完成，但并非總是如此。 如果您有1000筆交易，并且每毫秒進(jìn)行一次交易，那么您將獲得均勻的響應(yīng)時(shí)間。 我發(fā)現(xiàn)更有趣的是一天中最忙的一秒鐘的交易數(shù)量。 這樣可以指示系統(tǒng)應(yīng)該能夠處理的流速。

檢查微脈沖

考慮一個(gè)系統(tǒng)，該系統(tǒng)在相同的100微秒內(nèi)獲得30個(gè)事件，而這些突發(fā)相距100毫秒。 這看起來(lái)可能是每秒（30 / 0.1）300個(gè)事務(wù)，這聽起來(lái)相對(duì)容易，如果我們需要做的只是跟上進(jìn)度，但是如果我們希望盡快做出響應(yīng)，則短期/突發(fā)吞吐量為100中的30微秒或每秒300,000個(gè)事件。 換句話說，要盡可能快地處理微脈沖，您將需要一個(gè)系統(tǒng)，該系統(tǒng)可以處理的吞吐量比您在幾秒鐘，幾分鐘或一天內(nèi)預(yù)期的吞吐量高出多個(gè)數(shù)量級(jí)。 理想情況下，系統(tǒng)的吞吐量將是一天中最忙的一秒鐘的100倍。 在不減慢對(duì)這些數(shù)據(jù)突發(fā)的處理速度的情況下，每秒處理最繁忙的10毫秒所需的時(shí)間。

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

低垃圾率

最小化垃圾是避免GC暫停的關(guān)鍵。 為了有效地使用L1和L2高速緩存，您需要保持非常低的垃圾率。 如果您沒有有效地使用這些緩存，則您的應(yīng)用程序速度可能會(huì)慢2-5倍。 Chronicle中的垃圾非常低，您可以處理一百萬(wàn)個(gè)事件，而無(wú)需jstat檢測(cè)到您創(chuàng)建了任何垃圾。 jstat僅在分配了新的TLAB時(shí)顯示4 KB的倍數(shù)。 編年史確實(shí)會(huì)產(chǎn)生垃圾，但是它非常低。 即每百萬(wàn)個(gè)事件進(jìn)程幾個(gè)對(duì)象。 一旦將GC暫停設(shè)置為可管理或不存在，您就開始看到系統(tǒng)中的其他延遲源。 拿走巨石，您開始看到巖石。 拿走巖石，您開始看到鵝卵石。

支持全部寫入模型。

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

記事本與操作系統(tǒng)的交互最少。

系統(tǒng)調(diào)用速度很慢，如果可以避免調(diào)用操作系統(tǒng)，則可以節(jié)省大量的延遲。 例如，如果在回送時(shí)通過TCP發(fā)送消息，則在寫入和讀取數(shù)據(jù)之間可能會(huì)增加10微秒的延遲。 您可以寫入編年史，這是對(duì)內(nèi)存的簡(jiǎn)單寫操作，也可以從編年史中讀取，這也是從內(nèi)存中讀取的內(nèi)容，延遲為0.2微秒。 （正如我之前提到的，您也會(huì)獲得持久性）

無(wú)需擔(dān)心堆滿。

無(wú)限制隊(duì)列的常見問題，這使用了一個(gè)開放式堆。 Chronicle通過不使用堆來(lái)存儲(chǔ)數(shù)據(jù)，而是使用內(nèi)存映射文件來(lái)解決此問題。 通過使數(shù)據(jù)更緊湊，可以提高內(nèi)存利用率，但也意味著1 GB的JVM一天可以流處理1 TB的數(shù)據(jù)，而不必?fù)?dān)心堆或您擁有多少主內(nèi)存。 在這種情況下，無(wú)界隊(duì)列變得更易于管理。

結(jié)論

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

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

it編年史

總結(jié)

以上是生活随笔為你收集整理的it编年史_Java的编年史和低延迟的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。