來源: 石杉的架構(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)性能唬滑。
