原创 JVM參數優化(基礎篇)

這幾天壓測預生產環境,發現TPS各種不穩。因爲是重構的系統,據說原來的系統在高併發的時候一點問題沒有,結果重構的系統被幾十個併發壓一下就各種不穩定。雖然測試的同事沒有說啥,但自己感覺被啪啪的打臉。。。 於是各種排查,最先想到的就是JVM參

原创 使用 QJM 實現 HDFS 的 HA

本文是在hadoop集羣部署(yarn)基礎上增加的配置內容,因爲那篇缺少HDFS的HA配置,在生產環境不夠完整。 hadoop官方提供了兩種HDFS的HA配置方案,兩種方案殊途同歸,但是需要的錢、精力和技術不同。 如果對HDFS架構熟悉

原创 java.lang.OutOfMemoryError:GC overhead limit exceeded

java.lang.OutOfMemoryError這個錯誤是比較經典的錯誤了,經過JDK不斷的迭代,服務器硬件的不斷升級。。。總之,社會在發展,時代在進步。很多錯誤已經消失在時代的浪潮中。我也是很久沒有見過這個錯誤了,以至於都以爲在Ja

原创 常用消息隊列對比

作爲中間件,消息隊列是分佈式應用間交換信息的重要組件。消息隊列可駐留在內存或磁盤上, 隊列可以存儲消息直到它們被應用程序讀走。通過消息隊列,應用程序可以在不知道彼此位置的情況下獨立處理消息,或者在處理消息前不需要等待接收此消息。所以消息隊

原创 中文字節長度引起的數據丟失

最近在寫一個應用監控的項目,使用netty作爲數據傳輸。因爲剛開始寫,沒有使用Protobuf之類的作爲編碼工具,只是使用的是netty自帶的LengthFieldBasedFrameDecoder作爲報文解析工具,自定義編碼解碼類,實現

原创 ResourceManager HA 配置

陸續的把Hadoop集羣部署、HDFS的HA配置完成,把ResourceManager的HA配置好之後,Hadoop集羣配置也算是完整了,可以滿足小型中型生產環境Hadoop集羣搭建的需要。如果真要搭建超大型的Hadoop集羣,這些只能算

原创 YARN 架構

對Hadoop有過了解的都知道,Hadoop經歷過很長一段時間的版本號混亂和架構調整,YARN是Hadoop 2.0(或者早期的0.23.x)提出的資源管理、任務調度框架。解決了很多Hadoop 1.0(或者0.21.x、0.22.x)時

原创 HTTP長連接和短連接

主頁:www.howardliu.cn 博文:HTTP長連接和短連接 一直聽別人說HTTP長連接,只知道長連接比短連接更節省資源、更快捷,但是並不真的知道原因。知其然不知其所以然,對於技術來說,這種狀態是比較危險的。所以,還是要挖一下