高併發下架構師爲何更喜歡進程內緩存

進程內緩存是指緩存和應用程序在相同地址空間。即同一個進程內。分佈式緩存是指緩存和應用程序位於不一樣進程的緩存，一般部署在不一樣服務器上。

從前有個機構，機構的主人叫作 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. 進程內緩存的數據類型幾乎能夠是語言級別支持的任意類型，數據類型設計上比大多數分佈式緩存設備支持要靈活許多。

在應對高併發的狀況下，若是有適當的環境菜菜仍是以爲進程內緩存爲首選，另一點程序要儘可能避免線程切換，儘可能異步化。若是能夠最好能預估出緩存數據的大小，避免內存泄漏等現象發生。

固然分佈式緩存有本身的優點，在監控，容災，擴展性，易用性等方面更勝一籌。至於用進程內仍是分佈式緩存，沒有定論，能解決業務痛點就是最好的結果

寫在最後

程序若是要想最大程度的提高併發量，縮短響應時間， 就把用戶須要的數據放在離用戶最近的地方

---

添加關注，查看更精美版本，收穫更多精彩