在這種情況下是否有任何可行的設計模式？

Question

我們有一個系統（Java Web應用程序）已經進行了很長時間的主動開發/維護（大約十年）。

我們正在尋找的是為Web應用程序實現RESTful API。 這個使用Jersey的Web應用程序將是一個單獨的項目，旨在使其能夠與主應用程序一起運行或部署在雲中。

由於我們的應用程序的性質和年代，我們不得不在數據庫（postgres）之上實現一個（某種程度上）全面的緩存層，以幫助減少負載。 無論如何，對於RESTful API，其想法是GET請求將首先進入緩存而不是數據庫，以保持數據庫的負載。

將以某種方式填充緩存，以幫助確保已注冊的API用戶將需要的大多數東西都放在其中。

如果存在高速緩存未命中，則應從數據庫中檢索所需的數據（在此過程中也要輸入到高速緩存中）。

顯然，這與我代碼中的RESTful端點方法保持透明。 我們提出了創建“代理”來處理與數據庫和緩存之間的通信的想法。 REST層將簡單地傳遞ID（如果要檢索）或填充的Java對象（如果要插入/更新），並且代理將負責檢索/更新/無效等。

還存在可擴展性問題。 首先，API將與其余服務器一起使用，因此對數據庫的訪問不會成為問題，但是，如果我們將其部署到雲中，則將需要與系統進行通信的其他Broker實施（即數據庫）的方式有所不同（可能通過使用內部API）。

我已經對如何實現這一目標有了一個粗略的想法，但令我震驚的是，這可能是一個存在適當模式的問題。 如果我能遵循既定模式而不是提出自己的解決方案，那將是一個更好的選擇。 有任何想法嗎？

Answer 1

Ehcache具有這樣的緩存實現，它稱為SelfPopulatingCache 。

向緩存而不是數據庫發出請求。 然后，如果發生緩存未命中，Ehcache將代表您調用數據庫（或您擁有的任何外部數據源）。

您只需要實現一個具有單個方法的CacheEntryFactory ：

Object createEntry(Object key) throws Exception;

顧名思義，Ehcache用一個非常標准的工廠模式實現了這個概念。

Answer 2

沒有模式。 只需將初始DB服務隱藏在接口后面，圍繞其預期行為構建測試，然后切換到使用緩存層的實現即可。 我想依賴注入將是幫助您做到這一點的最好方法？

Answer 3

聽起來裝飾器模式會滿足您的需求： http : //en.wikipedia.org/wiki/Decorator_pattern 。

您可以創建用於數據訪問的DAO界面，例如：

Value get(long id);

首先創建一個直接的DB實現，然后創建一個調用基礎DAO實例的Cache實現，在這種情況下，它應該是DB實現。

緩存實現將嘗試從其自己的托管緩存中獲取價值，並在失敗時從底層DAO獲取價值。

因此，您的舊應用程序或REST都只能看到DAO界面，而無需了解任何強制執行的詳細信息，並且將來您可以自由更改實現。

Answer 4

透明地高速緩存HTTP請求的最佳設計模式是使用一個 HTTP 緩存 。