使用Redis作爲REST API的中介緩存

我們有一個iOS應用通過REST API與django服務器通信。大部分數據由相當大的Item對象組成，這些對象涉及一些呈現爲單個平面字典的相關模型，而且這些數據很少會發生變化。使用Redis作爲REST API的中介緩存

我們發現，查詢這對Postgres不是問題，但生成JSON響應需要花費大量的時間。另一方面，項目收集因人而異。

我想到了一個渲染系統，我們只需爲Item對象創建一個字典並將其保存爲redis作爲JSON字符串，這樣我們就可以直接從redis服務API（例如HMGET（用戶庫中的項目ID）），這是很快的，並使得它更容易重新生成「渲染的實例」，基本上只有post_save信號

我不知道這個設計有多好，是否有任何主要缺陷？也許有更好的方法任務？

來源

2013-04-24 Dmitry Shevchenko

json響應有多大以及轉儲json需要多長時間？ – 2013-04-25 08:43:25

說大約300個字符與他們的20個鍵與一些嵌套的字典，tastypie和django-rest-framework渲染那些在MBPr – 2013-04-25 08:57:45

上的長達1秒你是否嘗試過使用cjson或ultra json？ – 2013-04-25 09:04:58

當然，我們在我們公司也這樣做，使用Redis來存儲不是JSON，而是存儲從後端數據庫爲RESTful請求生成的大型XML字符串，並且它可以節省大量網絡跳躍和開銷。

有幾件事情要記住，如果這是你使用Redis的第一次...

專用的Redis服務器
的Redis是單線程的，應在專用服務器上進行部署足夠的CPU功率。不要在將它部署到您的應用程序或數據庫服務器上時發生錯誤。

高可用性
使用主/從複製設置Redis以實現高可用性。我知道Redis cluster已經取得了很多進展，所以你可能也想看看HA也是如此。

緩存命中/缺失
當檢查Redis的一個高速緩存「命中」，如果連接是死亡或出現任何異常，不失敗的請求，只是默認的數據庫;緩存應該始終是「盡力而爲」，因爲數據庫總是可以作爲最後的手段使用。

來源

2013-04-24 19:18:18 raffian

感謝您的提示！你的Redis服務器有什麼樣的負載？我們剛剛開始，到目前爲止，它看起來像一個EC2實例就足夠了 – 2013-04-24 19:30:07

Redis將是您遇到瓶頸的最後一個地方。我們的redis服務器在RedHat Linux Enterprise上運行，具有1個雙核CPU/4GB RAM;根據我們的測試，25K根據我們的有效載荷（25-100Kb）讀取第二次和第二次讀取，而Redis甚至沒有出汗;它完全踢屁股。 – raffian 2013-04-24 19:39:36

使用Redis作爲REST API的中介緩存

回答

相關問題