進程內緩存與進程外緩存相比（Redis、memcache），沒有網絡開銷，節省了內網帶寬，響應延時更低。但如果應用集群部署，緩存是在每個服務節點內，數據存了多份，一致性比較難保障。
如何保證進程內緩存的數據一致性？
答：保障進程內緩存一致性，有幾種方案。
第一種方案，可以通過單節點通知其他節點。如上圖：寫請求發生在server1，在修改完自己內存數據與數據庫中的數據之后，可以主動通知其他server節點，也修改內存的數據。
這種方案的缺點是：同一功能的一個集群的多個節點，相互耦合在一起，特別是節點較多時，網狀連接關系極其復雜。
第二種方案，可以通過MQ通知其他節點。如上圖，寫請求發生在server1，在修改完自己內存數據與數據庫中的數據之后，給MQ發布數據變化通知，其他server節點訂閱MQ消息，也修改內存數據。
這種方案雖然解除了節點之間的耦合，但引入了MQ，使得系統更加復雜。
前兩種方案，節點數量越多，數據冗余份數越多，數據同時更新的原子性越難保證，一致性也就越難保證。
第三種方案，為了避免耦合，降低復雜性，干脆放棄了“實時一致性”，每個節點啟動一個timer，定時從后端拉取最新的數據，更新內存緩存。在有節點更新后端數據，而其他節點通過timer更新數據之間，會讀到臟數據。
為什么不能頻繁使用進程內緩存？
答：分層架構設計，有一條准則：站點層、服務層要做到無數據無狀態，這樣才能任意的加節點水平擴展，數據和狀態盡量存儲到后端的數據存儲服務，例如數據庫服務或者緩存服務。
可以看到，站點與服務的進程內緩存，實際上違背了分層架構設計的無狀態准則，故一般不推薦使用。
什么時候可以使用進程內緩存？
答：以下情況，可以考慮使用進程內緩存。
情況一，只讀數據，可以考慮在進程啟動時加載到內存。
畫外音：此時也可以把數據加載到redis / memcache，進程外緩存服務也能解決這類問題。
情況二，極其高並發的，如果透傳后端壓力極大的場景，可以考慮使用進程內緩存。
例如，秒殺業務，並發量極高，需要站點層擋住流量，可以使用內存緩存。
情況三，一定程度上允許數據不一致業務。
例如，有一些計數場景，運營場景，頁面對數據一致性要求較低，可以考慮使用進程內頁面緩存。
末了，再次強調，進程內緩存的適用場景並不如redis/memcache廣泛，不要為了炫技而使用。
