來源: 石杉的架構(gòu)筆記
1、是否依賴Java系統(tǒng)自身內(nèi)存處理數(shù)據(jù)烫饼?
先說明一點猎塞,不管是我們自己開發(fā)的Java應(yīng)用系統(tǒng),還是一些中間件系統(tǒng)杠纵,在實現(xiàn)的時候都需要選擇是否基于自己Java進程的內(nèi)存來處理數(shù)據(jù)荠耽。
大家應(yīng)該都知道,Java比藻、Scala等編程語言底層依賴的都是JVM铝量,那么只要是使用JVM,就可以考慮在JVM進程的內(nèi)存中來放置大量的數(shù)據(jù)银亲。
還是給大家舉個例子慢叨,大家應(yīng)該還記得之前聊過消息中間件系統(tǒng)。
比如說系統(tǒng)A可以給系統(tǒng)B發(fā)送一條消息务蝠,那么中間需要依賴一個消息中間件拍谐,系統(tǒng)A要先把消息發(fā)送到消息中間件,然后系統(tǒng)B從這個消息中間件消費到這條消息馏段。
大家看下面的示意圖
大家應(yīng)該都知道轩拨,一條消息發(fā)送到消息中間件之后,有一種處理方式院喜,就是把這條數(shù)據(jù)先緩沖在自己的JVM內(nèi)存里亡蓉。
然后過一段時間之后,再從自己的內(nèi)存刷新到磁盤上去够坐,這樣可以持久化保存這條消息寸宵,如下圖。
2元咙、依賴Java系統(tǒng)自身內(nèi)存的缺陷
如果用類似上述的方式梯影,依賴Java系統(tǒng)自身內(nèi)存處理數(shù)據(jù),比如說設(shè)計一個內(nèi)存緩沖區(qū)庶香,來緩沖住高并發(fā)寫入的大量消息甲棍,那么是有其缺陷的。
最大的缺陷赶掖,其實就是JVM的GC問題感猛,這個GC就是垃圾回收,這里簡單說一下他是怎么回事奢赂。
大家可以想一下陪白,如果一個Java進程里老是塞入很多的數(shù)據(jù),這些數(shù)據(jù)都是用來緩沖在內(nèi)存里的膳灶,但是過一會兒這些數(shù)據(jù)都會寫入磁盤咱士。
那么寫入磁盤之后,這些數(shù)據(jù)還需要繼續(xù)放在內(nèi)存里嗎轧钓?
明顯是不需要的了序厉,此時就會依托JVM垃圾回收機制,把內(nèi)存里那些不需要的數(shù)據(jù)給回收掉毕箍,釋放掉那些內(nèi)存空間騰出來弛房。
但是JVM垃圾回收的時候,有一種情況叫做stop the world而柑,就是他會停止你的工作線程文捶,就專門讓他進行垃圾回收。
這個時候牺堰,他在垃圾回收的時候拄轻,有可能你的這個中間件系統(tǒng)就運行不了了。
比如你發(fā)送請求給他伟葫,他可能都沒法響應(yīng)給你恨搓,因為他的接收請求的工作線程都停了,現(xiàn)在人家后臺的垃圾回收線程正在回收垃圾對象筏养。
大家看下圖:
雖然說現(xiàn)在JVM的垃圾回收器一直在不斷的演進和發(fā)展斧抱,從CMS到G1,盡可能的在降低垃圾回收的時候的影響渐溶,減少工作線程的停頓辉浦。
但是你要是完全依賴JVM內(nèi)存來管理大量的數(shù)據(jù),那在垃圾回收的時候茎辐,或多或少總是有影響的宪郊。
所以特別是對于一些大數(shù)據(jù)系統(tǒng)掂恕,中間件系統(tǒng),這個JVM的GC(Garbage Collector弛槐,垃圾回收)問題懊亡,真是最頭疼的一個問題。
3乎串、優(yōu)化為依賴OS Cache而不是JVM
所以類似Kafka店枣、Elasticsearch等分布式中間件系統(tǒng),雖然也是基于JVM運行的叹誉,但是他們都選擇了依賴OS Cache來管理大量的數(shù)據(jù)鸯两。
也就是說,是操作系統(tǒng)管理的內(nèi)存緩沖长豁,而不是依賴JVM自身內(nèi)存來管理大量的數(shù)據(jù)钧唐。
具體來說,比如說Kafka吧匠襟,如果你寫一條數(shù)據(jù)到Kafka逾柿,他實際上會直接寫入磁盤文件。
但是磁盤文件在寫入之前其實會進入os cache宅此,也就是操作系統(tǒng)管理的內(nèi)存空間机错,然后過一段時間,操作系統(tǒng)自己會選擇把他的os cache的數(shù)據(jù)刷入磁盤父腕。
然后后續(xù)在消費數(shù)據(jù)的時候弱匪,其實也會優(yōu)先從os cache(內(nèi)存緩沖)里來讀取數(shù)據(jù)。
相當于寫數(shù)據(jù)和讀數(shù)據(jù)都是依托于os cache來進行的璧亮,完全依托操作系統(tǒng)級別的內(nèi)存區(qū)域來進行萧诫,讀寫性能都很高。
此外枝嘶,還有另外一個好處帘饶,就是不要依托自身JVM來緩沖大量的數(shù)據(jù),這樣可以避免復(fù)雜而且耗時的JVM垃圾回收操作群扶。
大家看下面的圖及刻,其實就是一個典型的Kafka的運行流程。
然后比如Elasticsearch竞阐,他作為一個現(xiàn)在最流行的分布式搜索系統(tǒng)缴饭,也是采用類類似的機制。
大量的依賴os cache來緩沖大量的數(shù)據(jù)骆莹,然后在進行搜索和查詢的時候颗搂,也可以優(yōu)先從os cache(內(nèi)存區(qū)域)中讀取數(shù)據(jù),這樣就可以保證非常高的讀寫性能幕垦。
4丢氢、經(jīng)驗之談
依賴os cache的系統(tǒng)JVM內(nèi)存越大越好傅联?
現(xiàn)在就可以進入主題了,就以上述說的kafka疚察、elasticsearch等系統(tǒng)纺且,線上生產(chǎn)環(huán)境部署時,是依賴os cache來緩沖大量數(shù)據(jù)的稍浆。
那么,給他們分配JVM堆內(nèi)存大小的時候是越大越好嗎猜嘱?
明顯不是衅枫,假如你有一臺機器,32GB的內(nèi)存朗伶,你如果在搞不清狀況的情況下弦撩,傻傻的認為還是給JVM分配越大內(nèi)存越好,比如給了16G的堆內(nèi)存空間給JVM论皆。
那么這樣分配下來益楼,os cache剩下的內(nèi)存,可能就不到10GB了点晴,因為本身其他的程序還要占用幾個GB的內(nèi)存感凤。
那如果是這樣的話,就會導(dǎo)致你在寫入磁盤的時候粒督,os cache能容納的數(shù)據(jù)量很有限陪竿。
比如說一共有20G的數(shù)據(jù)要寫入磁盤,現(xiàn)在就只有10GB的數(shù)據(jù)可以放在os cache里屠橄,然后另外10GB的數(shù)據(jù)就只能放在磁盤上族跛。
此時讀取數(shù)據(jù)時,起碼有一半的讀取請求锐墙,必須從磁盤上去讀礁哄,沒法從os cache里讀,如下圖所示:
那此時你有一半的請求都是從磁盤上在讀取數(shù)據(jù)溪北,必然會導(dǎo)致性能很差桐绒。
所以很多人在用Elasticsearch的時候就是這樣的一個問題,老是覺得ES讀取速度慢之拨,幾個億的數(shù)據(jù)寫入ES掏膏,讀取的時候要好幾秒。
那能不花費好幾秒嗎敦锌?你要是ES集群部署的時候馒疹,給JVM內(nèi)存過大,給os cache留了幾個GB的內(nèi)存乙墙,導(dǎo)致幾億條數(shù)據(jù)大部分都在磁盤上颖变,不在os cache里生均,最后讀取的時候大量讀磁盤,耗費個幾秒鐘是很正常的腥刹。
5马胧、正確的做法
針對場景合理給os cache更大內(nèi)存
所以說,針對類似Kafka衔峰、Elasticsearch這種生產(chǎn)系統(tǒng)部署的時候佩脊,應(yīng)該要給JVM比如6GB或者幾個GB的內(nèi)存就可以了。
因為他們可能不需要耗費過大的內(nèi)存空間垫卤,不依賴JVM內(nèi)存管理數(shù)據(jù)威彰,當然具體是設(shè)置多少,需要你精準的壓測和優(yōu)化穴肘。
但是對于這類系統(tǒng)歇盼,應(yīng)該給os cache留出來足夠的內(nèi)存空間
比如32GB內(nèi)存的機器,完全可以給os cache留出來20多G的內(nèi)存空間评抚,那么此時假設(shè)你這臺機器總共就寫入了20GB的數(shù)據(jù)豹缀,就可以全部駐留在os cache里了。
然后后續(xù)在查詢數(shù)據(jù)的時候慨代,不就可以全部從os cache里讀取數(shù)據(jù)了邢笙,完全依托內(nèi)存來走,那你的性能必然是毫秒級的侍匙,不可能出現(xiàn)幾秒鐘才完成一個查詢的情況鸣剪。
整個過程,如下圖所示:
所以說丈积,建議大家在線上生產(chǎn)系統(tǒng)引入任何技術(shù)的時候筐骇,都應(yīng)該先對這個技術(shù)的原理,甚至源碼進行深入的理解江滨,知道他具體的工作流程是什么铛纬,然后針對性的合理設(shè)計生產(chǎn)環(huán)境的部署方案,保證最佳的生產(chǎn)性能唬滑。