微云 linux

總覽

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

微云

這是我用來描述單個線程來完成當前由多個服務器完成的工作的術語。 （或與將單個應用程序部署到多臺計算機的趨勢相反）

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

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

這樣做的好處是您擁有一個確定性系統，該系統在體系結構上非常簡單。 該系統具有確定性，因為您記錄了每個入站和出站消息，這些記錄可能具有微秒級的計時，并且系統的行為是完全可復制的（并且可重新啟動的）。 注意：其后果之一是，僅重新啟動失敗的服務將無濟于事。 如果基于特定消息的特定方式失敗一次，則每次重新啟動時都應以完全相同的方式失敗。 這使得重現問題和測試變得更加容易。

為什么這么快？

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

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

避免產生垃圾的真正原因

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

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

結論

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

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

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

微云 linux

總結

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

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