我不知道為什么你會選擇對特定數量的“錯誤”（或警告）如此具體。聽起來您正在尋找將要發布到 Yahoo! 的某些文章的內容。 Insider (N Foos to Blah for the BlahBlah)。
那說：
當您考慮使用 redis 時，我建議您考慮以下幾點：
選擇一致的方式來命名您的密鑰并為其添加前綴。管理您的命名空間。
創建一個關鍵前綴或模式的“注冊表”，將每個前綴或模式映射到“擁有”它們的內部應用程序（并在維基中記錄這些，perhaos）
對于您放入 Redis 基礎設施的每一類數據：設計、實施和測試垃圾收集和/或數據遷移到存檔存儲的機制。
在對應用程序部署進行大量投資之前，設計、實施和測試分片（一致散列）庫，并確保在每個服務器上保留復制的“分片”注冊表。
將您所有的 K/V 存儲和相關操作隔離到您自己的庫/API 或服務中，并以無情和無情的鐵手絕對強制使用該 API/服務
讓我依次解釋這些要點：
您應該從一開始就假設您的 Redis 基礎設施將是許多應用程序或單獨模塊使用的公共資源。每個服務器上可以有多個數據庫（默認編號為 0 到 31，但您可以增加這些數據庫的數量）。但是，最好假設您需要使用鍵前綴來避免各種不同應用程序/模塊之間的沖突。
一致的鍵前綴：管理您的命名空間：
您的應用程序/模塊應該提供動態更改這些鍵前綴的靈活性。確保所有鍵都是從應用程序/模塊前綴與您正在操作的鍵連接起來合成的；禁止對關鍵字符串進行硬編碼。
注冊表：記錄和跟蹤您的命名空間：
我建議您在 Redis 服務器上“保留”某些關鍵模式（前綴或全局模式）。例如，您可以將 __key_registry__（類似于 Python 保留方法/屬性名稱）作為 URL 的關鍵前綴的哈希，進入您的 wiki 或 Trac 或您使用的任何內部文檔站點。因此，您可以對數據庫內容進行管理，并追蹤誰/什么對您在任何數據庫中找到的每個鍵負責。 （制定一項政策，即任何與您的注冊表中的任何模式不匹配的密鑰都可以/將被您的自動內務管理立即刪除）。
垃圾收集：
在持久的、共享的、鍵/值存儲中，特別是在 Redis 的情況下（其中完整的鍵/值存儲必須始終適合 RAM ---不推薦使用 VM/交換存儲）垃圾收集是可能是單一的主要維護問題。
因此，您需要考慮如何選擇需要從 Redis 遷移出的數據（可能會遷移到 SQL/RDBMS 或其他形式的存檔存儲中），以及您將如何跟蹤和清除數據這是過時的或無用的。
顯而易見的方法涉及使用 EXPIRE 或 EXPIREAT 功能/命令。這允許 Redis 為您管理垃圾收集，無論是相對于您對任何給定鍵的操作（創建或更新），還是根據絕對（自紀元以來的秒數）時間規范。關于 Redis 過期的唯一技巧是每次更新密鑰時都必須重新設置它。
這種方法適用于它自然適用的情況。但是，如果您想無限期地緩存數據/鍵并且只清理條目，則它沒有用。為此，我建議您使用“ZSET”——一個帶有值和“分數”的集合，可以通過這些分數的范圍來查詢……通常用于有序/排序的集合。在我的模型中，您將向集合、鍵及其關聯的時間戳添加項目（當您將相應的鍵/值添加或更新到數據庫本身時。然后您可以使用以下內容查詢該 ZSET：ZRANGEBYSCORE __EXPIRY__ 0 $SOME_EPOCH_TIME 獲取在特定時間之前添加/更新的這些子集。您可以迭代此結果，刪除相應的鍵/值對，直到您在服務器上釋放了足夠的空間來滿足您的需求（或完成了您為自己設置的其他垃圾收集要求）。
另一種有用的方法是維護一個或多個隊列（Redis 列表，由 RPUSH/LPUSH 和 RPOP/LPOP 命令、它們的 B* 阻塞表兄弟或相當棘手的 BRPOPLPUSH/RPOPLPUSH 命令操作），用于將事物持久化以使其更持久大容量存儲（例如您的 SQL RDBMS）?；旧?，這用作一個工作隊列，列出在 Redis 中已更改的鍵（可能還有某種形式的關于規范數據存儲的標識符），因此需要將其復制到您的大容量存儲中。您可以監控此類隊列的長度為 e確保您沒有遇到不斷增長的積壓。
分片：
Redis 不提供分片。您可能應該假設您將增長超出單個人 Redis 服務器的容量（從屬服務器用于冗余，而不是用于擴展，但如果您有某種方法來管理數據一致性，您可以將一些只讀操作卸載到從屬服務器—— - 例如，未到期描述的密鑰/時間戳值的 ZSET 也可用于一些離線批量處理操作；發布/訂閱功能也可用于主機提供有關所選密鑰/數據靜止的提示。
所以你應該考慮編寫自己的抽象層來提供分片?；旧舷胂笠幌拢阋呀泴崿F了一個一致的散列方法……在使用它之前，你通過它運行每個合成的密鑰。雖然您只有一個 Redis 服務器，但哈希到服務器的映射最終總是指向您唯一的服務器。稍后，如果您需要添加更多服務器，則可以調整映射，以便將一半或三分之一的密鑰解析到其他服務器。當然，您會希望實現這一點，以便主服務器上的故障導致您的庫/服務模塊在輔助服務器和可能的任何第三級服務器上自動重試。根據您的應用程序，您甚至可能會嘗試從另一個數據源（例如您的 SQL RDBMS）完全獲取某些類型的數據。
這是一個領域，特別是，我希望看到一個強大的第三方（或 antirez 創建）庫編寫來處理所有繁瑣地位置。一致的散列并不難……但它確實需要相當多的精心編寫的代碼來實現——而且它應該遠離大多數應用程序編碼人員。您想要一些可以正常工作并繼續工作的東西，即使您添加了額外的服務器容量（需要為所有受影響的密鑰遷移實用程序）和故障（要求您已經處理了將數據復制到二級和/或三級服務器） .
將您的 Redis 操作與您的應用程序分離：
我希望你已經看到了這個建議對我提出的所有其他建議的重要性的預示。如果有人只是將 Redis 基礎設施用作臨時的、無底的資源，那么這些都將不起作用。
不要將您的應用程序視為使用 Redis！
您正在編寫一個使用一組服務的應用程序。碰巧的是，（部分）這些服務是由 Redis 服務器提供的。但是，您應該將其視為實現細節，并專注于您需要哪些服務以及您向應用程序開發人員提供哪些 API 來提供這些服務。
Redis 提供的任何東西都不是您通過眾多替代方案無法完成的。如果您編寫正確類型的代碼（可能包括存儲過程、觸發器等和/或單獨的守護程序）并實現正確的模式，則可以在某種程度上使用 SQL/RDBMS 后端來近似或提供 Redis 的每個功能它。
如果您專注于需要提供給應用程序開發人員的 API，那么您就有希望更換那些不可避免地需要在以后更換（無論出于何種原因）的部分。您還可以在開發需要與現有數據庫交互的其他應用程序和模塊時提供更大的靈活性。
