進程內緩存，究竟怎么玩？
除了常見的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吧。
畫外音：額，介紹技術，不希望把大家帶偏了。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
