3
我正在嘗試使用Redis實施標記。這是它的樣子：Redis Keyspace通知 - 用戶數量與爭用數量
mykey (my item)
mykey:tags (a set with the tags associated to that item)
tags:tag1 (a set with references to all items tagged with "tag1")
...
我打算使用Redis Keyspace Notifications防止過期的鑰匙留在我的標籤永遠集（即使高速緩存中的每個項目都有一個缺省TTL設定，我不知道喜歡保持陳舊的數據）。
這些都是我考慮的選項：
1）在所有的 「過期」 事件。
psubscribe '[email protected]*:expired'
優點：
- 只有1訂戶。
缺點：
- 由於不是所有的項目包括標籤，我會檢查的myKey：標籤 ，如果存在獲得的標籤，並從每個標籤集合中刪除該項目。
- 該方法的爭用將隨着商店中的密鑰數量 而增加。
2）訂閱所有僅包含標籤的密鑰的事件。
psubscribe '[email protected]*:mykey'
優點：
- 訂閱將僅與標籤的項目被創建。
缺點：
- 必須有開銷每個用戶相關聯。
- 根據商店中已標記商品的數量 ，訂戶數量可以增長得相當快。
問題：
- 哪個選項我應該執行？我應該關注2）上的 訂戶數量還是1）更大的 交易的爭用？我無法找到關於此主題的任何建議。
- 最終的遊戲是在Redis集羣上實現這一點。這是否會添加 任何額外的關注實施？
更新1：
這是標註在我們的緩存之上的通用實現。在這一點上，我不確定我們是如何最終使用它的。這更像是我正在開發的PoC。試圖用一些數字來回答一些問題的意見：
- 卷：我們有幾千萬，每天的獨立訪客。並非所有存儲在緩存中的每個訪問者的項目都有標籤。但是這個不斷變化。
- 標籤：標籤管理。目前有幾十個標籤。我們正在考慮支持未來的免費文字標籤。
- 我還沒有測試過這兩種方法。我希望的選項之一是如此糟糕，甚至不是一種選擇:)
更新2：
一些試驗和錯誤後和一些研究，我放棄2）。 Redis客戶端和輸出緩衝區都有一個限制，這使得這個選項不可行。你可以找到更多的信息here和here。 我試過1）它工作得很好。我甚至將按鍵的期限設置爲彼此相隔5ms，並且代碼正確處理它。這可以成爲一種選擇。
另一個選項可以是@ thepirat000建議的選項。我將這個答案標記爲已接受的答案，但我也在他的建議中加入了一點小小的調整：我不想在每個標記操作的標記中進行維護，而是可以隨機確定何時執行此操作。這是一個很好的方法，它不使用pub/sub和密鑰空間通知。
@RyanVincent你是對的。到目前爲止，我所有的都是猜測。希望在我正在考慮的兩個選項之間有一條清晰的路徑。 –