歡迎光臨
每天分享高質量文章

程式員修神之路–高併發下為什麼更喜歡行程內快取

菜菜哥,告訴你一個好訊息

YY妹子,什麼好訊息,你有男票了?

不是啦,我做的一個網站,以前經常由於訪問量太大而崩潰,現在我加上了快取,很穩定啦

加的什麼快取呢?

我用的redis,號稱業界最快的快取組件了

你覺得現在的快取操作應該是最快的了嗎?

是的,我覺得沒有快取能比這種樣式更快了

你先停停,我給你先講個故事

行程內快取是指快取和應用程式在相同地址空間。即同一個行程內。分佈式快取是指快取和應用程式位於不同行程的快取,通常部署在不同服務器上。

        從前有個機構,機構的主人叫做 CPU,這個機構專門派僕人取一些東西然後做相應的處理。下麵是這個機構日常的場景。

cpu

趕緊去我的倉庫L1快取取點東西

僕人

主人你要的東西,那裡離我們最近,所以很快,但是空間比較小。

cpu

你丫還挺快,只用了大約一秒

cpu

趕緊去倉庫 L2快取取點東西

僕人

主人你要的東西,那裡離我們也很近,比L1快取遠一點,但是也很快,空間比較小,但是比L1快取的空間大。

cpu

速度還可以,大約20秒就回來了

cpu

街上有一個地方叫記憶體,趕緊去取點東西

僕人

主人你要的東西,記憶體這個地方空間很大呀,就是稍微遠了點

cpu

居然用了5分鐘,等你這段時間我都刷了好幾個段子了

cpu

有一個叫做磁盤的小鎮,趕緊去取點東西

僕人

主人你要的東西,磁盤這個地方空間太大呀,取點東西很慢呀

cpu

居然用了5天,等你這段時間我都能抱團來一個周邊游了

cpu

有一個叫做互聯網的國度,趕緊去取點東西

僕人

主人你要的東西,互聯網太遠了,取點東西太費勁了

cpu

居然用了15天,等你去互聯網取東西,簡直就是在浪費我的生命

cpu

當我做完一個委托人的任務,切換到另外一個委托人的任務時候,我需要把上一個委托人的一些信息先記錄下來,然後還需要把新委托人的信息讀取一遍,這個過程我是很耗時的,大約需要一個小時呢

以上故事純屬預估資料,真實資料會根據不同的硬體配置和網絡環境有誤差。

        通過以上不正經的小故事,我們可以瞭解到cpu取各個設備資料的大體差距。至於YY妹子的問題,大家也應該瞭解了。

1.  首先把資料從磁盤加載到記憶體做快取,這個是對的。畢竟磁盤的IO速度比記憶體要慢的多。就拿我們現在使用的大多數PC機以及服務器來說,磁盤往往是性能的瓶頸。

2.  如果有條件或者框架支持可以實現行程內快取,我還是推薦使用行程內快取,畢竟類似Redis這樣的kv儲存和應用程式多數情況不在一臺服務器上,雖然局域網的速度肉眼看起來非常快,但是對於cpu來講,還是讓cpu休了一個大假。

    至於什麼情況下適合應用行程內快取,我覺得有幾點需要註意:

1.  相同的請求或者設置的相同快取key的請求每次都是同一個服務器上的同一個程式去處理,這樣這個請求的快取正常情況下只會產生一份。 如果每次請求都會路由到不同的服務器,便會產生多個快取的副本,維護這些快取資料的一致性是需要代價的。

2.  當有新的服務器節點加入或者服務器節點退出的時候,不能發生雪崩現象,所有快取請求都穿透到達資料庫,那是比較要命的。比如可以看一下菜菜以前的文章:分佈式快取的一條明路(附代碼)

3.  如果快取的處理服務器發生變化,比如:由於某種原因,開始請求是由服務器A來處理,後來A服務器down了,現在由服務器B來處理,在快取轉移的過程中,必須能保證資料的正確性和一致性。

4.  程式的行程內快取必須有過期策略,在有限記憶體大小的情況下,合理的使用。推薦使用LRU淘汰演算法來保證記憶體不會撐爆。

5.  系統的併發量及其大,對性能的要求及其高,可以考慮使用行程內快取。

6.  如果是小部分只讀資料,並且訪問量比較大,例如經常使用的字典資料等,可以考慮使用行程內快取。

    相對於分佈式快取,比如Redis,行程內快取有哪些優勢呢?

1.  行程內快取性能比較高,延遲會更小,更節省帶寬,畢竟分佈式快取網絡呼叫的性能和本地呼叫比起來慢太多,

2.  由於和應用程式位於同一行程,共享相同的虛擬記憶體,所以在狀態維護上更容易一些,

3.  其次行程內的快取不設計到網絡傳輸,所以沒有序列化的過程,在性能上更勝一籌。

4.  行程內快取的資料型別幾乎可以是語言級別支持的任意型別,資料型別設計上比大多數分佈式快取設備支持要靈活許多。

        在應對高併發的情況下,如果有適當的環境菜菜還是覺得行程內快取為首選,另外一點程式要儘量避免執行緒切換,儘量異步化。如果可以最好能預估出快取資料的大小,避免記憶體泄漏等現象發生。

        當然分佈式快取有自己的優勢,在監控,容災,擴展性,易用性等方面更勝一籌。至於用行程內還是分佈式快取,沒有定論,能解決業務痛點就是最好的結果

寫在最後

程式如果要想最大程度的提升併發量,縮短響應時間, 就把用戶需要的資料放在離用戶最近的地方

程式員修神之路–高併發優雅的做限流(有福利)

程式員過關斬將–快速遷移10億級資料

程式員修神之路–分佈式快取的一條明路(附代碼)

程式員修仙之路–把用戶訪問記錄優化到極致

互聯網之路,菜菜與君一同成長!

識別二維碼更多精彩