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

        透過以上不正經的小故事，我們可以瞭解到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億級資料

●程式員修神之路–分散式快取的一條明路（附程式碼）

●程式員修仙之路–把使用者訪問記錄最佳化到極致