架構問題：客戶端REST API的緩存解決方案

Question

我正在實施一個高流量的客戶端Web應用程序，該應用程序使用大量REST API作爲雲數據庫的數據訪問層。我說客戶端是因爲它實現了REST而不提供它。

REST API在服務器端和客戶端都得到實現，我需要弄清楚緩存的一個好的解決方案。該應用程序正在Web農場運行，所以我傾向於像memcached這樣的分佈式緩存。這個緩存解決方案將需要像我的應用程序和REST API之間的代理層，並支持客戶端和服務器端。

例如，如果我打電話更新記錄，我會通過REST進行更新，並且希望在緩存中保留更新記錄，以便下次調用該記錄時不需要額外調用外部REST服務。

我想盡可能減少REST調用，並且需要儘可能保持數據的準確性，但它並不需要100％準確。

這個緩存代理的最佳解決方案是什麼？它是一個獨立的應用程序，可以在具有本地緩存​​的服務器上運行，也可以使用分佈式緩存構建到當前的解決方案中？你有什麼想法，建議或疑問

謝謝

Answer 1

你一針見血的頭部。您需要一個充當數據代理的緩存層。

我建議你創建一個可以稍微提取雲概念的圖層。你的客戶不應該關心數據來自哪裏。我會創建一個與雲和所有其他數據進行通信的存儲庫層。然後你可以在你的客戶端實際調用的頂層放置一個服務層。在這個服務層裏面，你會實現像緩存層一樣的東西。

我以前總是建議使用MemCached或MemCached Win32，這取決於您的環境。如果你在Windows世界中，MemCached win32的效果非常好！看看Enyim客戶端的MemCached win32 ...這是所有其他端口中最不成問題的。

如果你是開放的，但你在.net世界，那麼你可以嘗試Velocity。 MS最終得知他們的緩存框架存在漏洞，因爲他們需要支持農場概念。上次我檢查的速度沒有超出測試版，但仍然值得一看。

我通常建議從第一天起使用存儲庫和服務層的概念......即使你不需要它。它爲您的應用程序提供的靈活性是值得的，因爲您永遠都不知道應用程序需要插入哪個方向。需要擴展通常是需要這種靈活性的最佳理由。但通常當需要擴展時，需要現在擴展並在存儲庫層和服務層進行重構，而不是不可能通常是半複雜的。