SpringBoot透過refresh-ahead caching加速微服務效能

banq發表於2019-05-31
Spring Boot微服務

在設計微服務架構時，我們可能會遇到不同的效能問題。像Akka這樣的反應性框架提供了一種使微服務更具彈性的方法。但是，在處理耗時的演算法或緩慢的依賴系統時，快取可能是我們的最後手段，儘管它會帶來權衡。資料通常已過時，但可提供效能提升。

解決此問題的方法是Refresh-Ahead Caching，在提供效能提升的同時，它還提供了最新的資料。快取由微服務非同步重新載入，而客戶端僅訪問快速快取資源。您可以在Spring Boot專案中使用cache-refresh-ahead-spring-boot-starter啟用Refresh-Ahead Caching ，它是一個執行的排程程式，重新整理快取並支援Caffeine和Redis。您可以為所有快取指定重新整理間隔，也可以僅為特定快取指定重新整理間隔。

為了最小化快取鍵的大小，它使用類名，方法名和引數類。它解析了這些屬性並解開了CGLIB代理Bean。通常，當您向方法新增@Cacheable註釋時，該類將包裝在CGLIB代理Bean中。但是，此代理僅在其他類中可見。因此，您無法為私有方法啟用快取。這種解包允許排程程式在實際的Bean上呼叫該方法，而不會觸及快取。快取的值在較低階別時更新，因此它們不會覆蓋寫入時間。

當使用位於微服務中的快取並水平擴充套件時，您應該知道您的快取是分散的。您可能會遇到快取資料過於分散且客戶端訪問重新整理快取源的可能性較低的問題；您可能遇到的另一個問題是大量的微服務重新整理快取並耗盡後端。此外，如果使用@CachPut，則快取一致性可能會成為問題。因此，我建議僅在冗餘微服務量較少時才使用本地快取。

高度冗餘的微服務應使用共享的Redis快取。重新整理邏輯也應該與執行的微服務分開。例如，使用此方法，您可以執行10個訪問快取的微服務和3個（用於冗餘）只重新整理快取的微服務，因此您不必擔心耗盡後端或分散的快取。

該文介紹瞭如何使用Redis來實現分散式系統中的併發控制。使用Redis來控制快取的重新整理率。Redis是一個記憶體資料儲存，速度極快。它還具有原子屬性，這使得它非常適合為併發控制建立鎖和訊號量，使用Redis讓一個程式每90秒重新整理一次快取。效果立竿見影，激動人心，令人難以置信：API請求從每90秒約6,000個減少到一個。
 

相關文章