尋找以下問題的存儲溶液，優選與一些的NoSQL般的速度和可擴展性：NoSQL作爲發佈 - 訂閱/多讀者隊列的存儲嗎？
活動。其中很多，每個事件的數據很少。這是我們需要存儲的。
這將是很好不存儲每個事件的多個拷貝（如在每個觀察者單獨的存儲）。
觀察員。他們幾個（< 50）他們需要閱讀的事件
以自己的節奏（拉模型）
最好
每個觀察者都需要閱讀每個事件（最終）
不保證他們多久會提出更改。在閱讀之前可能需要存儲大量事件。
在RDBMS你可能只是編號的事件順序，並記住「最後讀不」每一個觀察者。在交易某些ACID時，是否有可能實現類似的操作來提高可擴展性&？
到目前爲止Redis的，其名單看起來不錯 - 我應該看什麼好？
我認爲Redis的列表是一個不錯的選擇。我會爲每個觀察者名單，雖然去 - 這樣，你有O（1）閱讀並RPUSH/LPOP寫，當所有觀察家都收到他們的事件自動從系統中消失。
可以減少通過只存儲在每個列表的事件ID每一個觀看所需的存儲空間，不過那麼你將需要保留一個計數器，每個事件，以確定它可以從系統中刪除。
要與一個列表落實，建立具有每經過一個事件被添加到列表的頭部時間的計數器。還爲每個客戶設置一個計數器，指示他們收到了多少事件。這些差異是您需要從列表中獲得的項目數量。
這種方法的缺點是，新項目可以被添加到列表中，你檢查櫃檯後。你可以通過從列表的尾部開始計算，但是這是O（N）而不是O（1）。您可以通過從列表中修剪接收到的事件來減少N，並且還可以爲尾部位置維護一個計數器 - 工作的效果取決於觀察者離線時可以累積的事件數量。
你可以看看它是如何在做Tarantool，用一個Lua程序，以保持一個環形緩衝區事件： https://github.com/mailru/tntlua/blob/master/notifications.lua
謝謝。 Redis的列表確實看起來很合適。我唯一懷疑Redis的是它的內存限制（RAM很便宜，但可能不是*便宜:-)） – 2011-02-08 09:08:32