進程內緩存，究竟怎麼玩？

除了常見的redis/memcache等進程外緩存服務，緩存還有一種常見的玩法，進程內緩存。

什麼是進程內緩存？

答：將一些數據緩存在站點，或者服務的進程內，這就是進程內緩存。

進程內緩存的實現載體，最簡單的，可以是一個帶鎖的Map。又或者，可以使用第三方庫，例如leveldb。

進程內緩存能存儲啥？

答：redis/memcache等進程外緩存服務能存什麼，進程內緩存就能存什麼。

如上圖，可以存儲json數據，可以存儲html頁面，可以存儲對象。

進程內緩存有什麼好處？

答：與沒有緩存相比，進程內緩存的好處是，數據讀取不再需要訪問後端，例如資料庫。

如上圖，整個訪問流程要經過1,2,3,4四個步驟。

如果引入進程內緩存，

如上圖，整個訪問流程只要經過1,2兩個步驟。

與進程外緩存相比（例如redis/memcache），進程內緩存省去了網路開銷，所以一來節省了內網帶寬，二來響應時延會更低。

進程內緩存有什麼缺點？

答：統一緩存服務雖然多一次網路交互，但仍是統一存儲。

如上圖，站點和服務中的多個節點訪問統一的緩存服務，數據統一存儲，容易保證數據的一致性。

而進程內緩存，如上圖，如果數據緩存在站點和服務的多個節點內，數據存了多份，一致性比較難保障。

如何保證進程內緩存的數據一致性？

答：保障進程內緩存一致性，有幾種方案。

第一種方案，可以通過單節點通知其他節點。如上圖：寫請求發生在server1，在修改完自己內存數據與資料庫中的數據之後，可以主動通知其他server節點，也修改內存的數據。

這種方案的缺點是：同一功能的一個集群的多個節點，相互耦合在一起，特別是節點較多時，網狀連接關係極其複雜。

第二種方案，可以通過MQ通知其他節點。如上圖，寫請求發生在server1，在修改完自己內存數據與資料庫中的數據之後，給MQ發布數據變化通知，其他server節點訂閱MQ消息，也修改內存數據。

這種方案雖然解除了節點之間的耦合，但引入了MQ，使得系統更加複雜。

前兩種方案，節點數量越多，數據冗餘份數越多，數據同時更新的原子性越難保證，一致性也就越難保證。

第三種方案，為了避免耦合，降低複雜性，乾脆放棄了「實時一致性」，每個節點啟動一個timer，定時從後端拉取最新的數據，更新內存緩存。在有節點更新後端數據，而其他節點通過timer更新數據之間，會讀到臟數據。

為什麼不能頻繁使用進程內緩存？

答：分層架構設計，有一條準則：站點層、服務層要做到無數據無狀態，這樣才能任意的加節點水平擴展，數據和狀態盡量存儲到後端的數據存儲服務，例如資料庫服務或者緩存服務。

可以看到，站點與服務的進程內緩存，實際上違背了分層架構設計的無狀態準則，故一般不推薦使用。

什麼時候可以使用進程內緩存？

答：以下情況，可以考慮使用進程內緩存。

情況一，只讀數據，可以考慮在進程啟動時載入到內存。

畫外音：此時也可以把數據載入到redis / memcache，進程外緩存服務也能解決這類問題。

情況二，極其高並發的，如果透傳後端壓力極大的場景，可以考慮使用進程內緩存。

例如，秒殺業務，並發量極高，需要站點層擋住流量，可以使用內存緩存。

情況三，一定程度上允許數據不一致業務。

例如，有一些計數場景，運營場景，頁面對數據一致性要求較低，可以考慮使用進程內頁面緩存。

末了，再次強調，進程內緩存的適用場景並不如redis/memcache廣泛，不要為了炫技而使用。

更多的時候，還是老老實實使用redis/mc吧。

畫外音：額，介紹技術，不希望把大家帶偏了。

挖坑篇：《緩存架構，到底設計些什麼？》

填坑篇一：《從源碼分析，究竟選型redis還是memcache》

填坑篇二：《「選redis還是memcache」，面試官究竟想考察啥？》

任何脫離業務的架構設計都是耍流氓，希望大家有收穫，求轉。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！