微云 linux

總覽

我面臨的一個常見問題是： 如果是單個作者，多個讀者，如何縮放基于Chronicle的系統(tǒng)。 盡管有解決此問題的方法，但很有可能根本不會有問題。

微云

這是我用來描述單個線程來完成當(dāng)前由多個服務(wù)器完成的工作的術(shù)語。 （或與將單個應(yīng)用程序部署到多臺計(jì)算機(jī)的趨勢相反）

假設(shè)擴(kuò)展系統(tǒng)的唯一方法是分區(qū)或具有多個副本。 除非您同時擁有多個系統(tǒng)，否則這種擴(kuò)展并不總是那么好。 所有這些都增加了系統(tǒng)開發(fā)，部署和維護(hù)的復(fù)雜性。 我看到的一個常見問題是，開發(fā)人員不再能夠在其工作站或單元/功能測試中測試端到端系統(tǒng)

基于編年史的處理引擎具有不同的方法。 它們通常旨在處理您所能承受的最大負(fù)載。 即瓶頸在其他地方，例如與外部系統(tǒng)，網(wǎng)關(guān)和數(shù)據(jù)庫的接觸點(diǎn)。 基于Chronicle的處理引擎每秒可以處理100,000至1,000,000入站和出站事件，延遲介于1到10微秒之間。 這比網(wǎng)關(guān)可以向引擎輸入/輸出數(shù)據(jù)的速率高得多，因此從來沒有一個很好的分區(qū)用例。 這是一個選擇，但您不應(yīng)該認(rèn)為這是您需要的選擇。

這樣做的好處是您擁有一個確定性系統(tǒng)，該系統(tǒng)在體系結(jié)構(gòu)上非常簡單。 該系統(tǒng)具有確定性，因?yàn)槟涗浟嗣總€入站和出站消息，這些記錄可能具有微秒級的計(jì)時，并且系統(tǒng)的行為是完全可復(fù)制的（并且可重新啟動的）。 注意：其后果之一是，僅重新啟動失敗的服務(wù)將無濟(jì)于事。 如果基于特定消息的特定方式失敗一次，則每次重新啟動時都應(yīng)以完全相同的方式失敗。 這使得重現(xiàn)問題和測試變得更加容易。

為什么這么快？

一個線程中的一個單線程處理引擎具有

• 無鎖
• 沒有TCP延遲
• 可以鎖定到內(nèi)核或CPU，以改善緩存行為。
  也就是說，它永遠(yuǎn)不會上下文切換或放棄CPU。
• 可重用的可變對象更加實(shí)用，因此您可以避免用垃圾攪亂緩存，從而使內(nèi)存訪問速度提高5倍。 （有了獎金，您將不再具有GC暫停）

避免產(chǎn)生垃圾的真正原因

大多數(shù)Java應(yīng)用程序中的一個常見問題是GC暫停時間。 您通常希望將其最小化。 我主張減少產(chǎn)生的垃圾，但是我不擔(dān)心GC暫停，因?yàn)槲疫€沒有編寫一個可以在交易四年后暫停的系統(tǒng)。 我通過使Eden大小大于一天中產(chǎn)生的垃圾量來做到這一點(diǎn)，并在維護(hù)窗口中進(jìn)行System.gc（）處理（視情況在深夜或周末）。 在低延遲的應(yīng)用程序中避免垃圾的主要原因是創(chuàng)建垃圾會導(dǎo)致緩存的滾動或刷新。 如果您有一個系統(tǒng)（套接字上的所有JVM）產(chǎn)生200 MB / s的垃圾，并且有20 MB的L3高速緩存，則您每隔0.1秒就會有效地用垃圾填充高速緩存。 對L3高速緩存的內(nèi)存訪問可以比對主內(nèi)存的訪問快5倍。

注意： L3緩存在套接字的所有內(nèi)核之間共享，因此，如果要在所有內(nèi)核上實(shí)現(xiàn)可伸縮性，則要使用L1緩存（通常為32 KB），并且如果有繁忙的線程在創(chuàng)建32 MB / s的垃圾，這是每毫秒就會充滿垃圾。

結(jié)論

因此，我開始使用術(shù)語“微云”。 即在一個線程中完成整個云的工作。 我有幾個這樣做的客戶。 跨一個系統(tǒng)的許多JVM所做的工作只能通過一個非常快的線程來完成。 顯然，在一個工作站上測試一個線程要容易得多，并且在生產(chǎn)中占用數(shù)據(jù)中心的機(jī)架空間要少得多。

參考： Vanilla Java博客上的JCG合作伙伴 Peter Lawrey撰寫的編年史和微云 。

翻譯自: https://www.javacodegeeks.com/2013/02/chronicle-and-the-micro-cloud.html

微云 linux

總結(jié)

以上是生活随笔為你收集整理的微云 linux_编年史与微云的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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