總覽

盡管有許多可用于Java的高性能消息傳遞系統(tǒng)，但大多數(shù)都避免引用基準(zhǔn)，包括持久消息傳遞和消息的序列化/反序列化。 這樣做有很多原因。 1）您并不總是需要或想要持久消息2）您希望使用自己的序列化選項。 避免使用它們的一個重要原因是，這兩種方法都會使消息傳遞速度降低多達(dá)10倍，看起來并不那么好。 大多數(shù)消息傳遞基準(zhǔn)測試都會突出顯示傳遞原始字節(jié)而沒有持久性的性能，因為這提供了最高的數(shù)字。 有些還引用了持久消息編號，但是這些編號通常要慢得多。

如果您需要高效地對實際數(shù)據(jù)進行序列化和反序列化，并且即使您已學(xué)會了不使用這些數(shù)據(jù)，也想記錄和重播消息該怎么辦。

更高的性能序列化和耐用性

我已經(jīng)寫了一個庫，試圖解決更多的問題，正如我所看到的，以便為您提供更好的整體解決方案。 它不是可用的最快消息傳遞，但是它是持久的，并且包括序列化和反序列化時間。 正如我已經(jīng)指出的那樣，這可能比傳輸序列化數(shù)據(jù)的成本高10倍，因此在實際應(yīng)用中，該解決方案可以更快。

示例：發(fā)送價格

在此測試InProcessChronicleTest .testPricePublishing（）中，我發(fā)送價格事件，該事件包括一個較長的時間戳，一個符號，一個出價價格/數(shù)量和要價/數(shù)量。 寫入數(shù)據(jù)的時間為0.4 μS（0.0004毫秒），通過TCP連接接收數(shù)據(jù)的時間為1.8 μS。

注意：此連接在兩端都是持久的，因此您可以查看哪些數(shù)據(jù)已排隊發(fā)送和已接收。 如果連接丟失，即使服務(wù)器不可用（例如，重新啟動客戶端），它也可以從原來的位置繼續(xù)播放，或者可以選擇播放客戶端已經(jīng)收到的任何消息。

為了發(fā)送和接收500萬條消息，我使用了-Xmx32m -verbosegc標(biāo)志，該標(biāo)志表明只需要很少的堆，并且在此測試過程中沒有發(fā)生任何GC。 這意味著該庫對您的其余應(yīng)用程序影響很小。

與外部化對象進行比較。

為了說明這一點，我將其與在InProcessChronicleTest中序列化和反序列化包含相同數(shù)據(jù)的對象所需的時間進行了比較。 testSerializationPerformance（）。 PriceUpdate對象是可外部化的，并且該基準(zhǔn)測試 “比較JVM平臺上序列化庫的各個方面”表明，可外部化對象可以是可用的最快序列化之一。 在同一臺計算機上花費的時間是2.7 μS進行序列化和7.5 μS進行反序列化。 注意：這不包括消息傳遞或持久性，僅用于序列化和反序列化。

序列化 運輸 寫作時間 時間閱讀

Java紀(jì)事	TCP和持久性	0.4微秒	1.8微秒
可外部化	沒有	2.7微秒	7.5微秒
可序列化	沒有	3.8微秒	13.2微秒

結(jié)論

在對消息傳遞進行基準(zhǔn)測試時，您應(yīng)該包括發(fā)送和接收真實消息所花費的時間，而不僅是byte []，還包括持久性（如果需要）。

參考：我們的JCG合作伙伴 Peter Lawrey在Vanilla Java博客上的高性能持久消息 。

翻譯自: https://www.javacodegeeks.com/2013/02/high-performance-durable-messaging.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的高性能持久消息的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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