大部分時候，大家會用redis這類進程外緩存服務。有時候也使用進程內緩存。

什么是進程內緩存？

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

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

進程內緩存有什么好處？

答：與沒有緩存相比，進程內緩存的好處是，數據讀取不再需要訪問后端，例如數據庫。一來節省了內網帶寬，二來響應時延會更低。

進程內緩存有什么缺點？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 情況一，只讀數據，可以考慮在進程啟動時加載到內存。
• 情況二，極其高并發的，如果透傳后端壓力極大的場景，可以考慮使用進程內緩存。例如，秒殺業務，并發量極高，需要站點層擋住流量，可以使用進程內緩存。
• 情況三，一定程度上允許數據不一致業務。例如，有一些計數場景，運營場景，頁面對數據一致性要求較低，可以考慮使用進程內頁面緩存。

末了，再次強調，進程內緩存的適用場景并不如redis廣泛，不要為了炫技而使用。更多的時候，還是老老實實使用redis/mc吧。

知其然，知其所以然。

思路比結論更重要。