NoSQL作为发布 - 订阅/多读者队列的存储吗？

Question

寻找以下问题的存储溶液，优选与一些的NoSQL般的速度和可扩展性：

• 活动。其中很多，每个事件的数据很少。这是我们需要存储的。

  • 没有必要精确保持事件到达的顺序。

这将是很好不存储每个事件的多个拷贝（如在每个观察者单独的存储）。

• 观察员。他们几个（< 50）他们需要阅读的事件

  • 以自己的节奏（拉模型）

  • 以“让我读事件的下一块” API

    最好

  • 每个观察者都需要阅读每个事件（最终）

  • 不保证他们多久会提出更改。在阅读之前可能需要存储大量事件。

在RDBMS你可能只是编号的事件顺序，并记住“最后读不”每一个观察者。在交易某些ACID时，是否有可能实现类似的操作来提高可扩展性&？

到目前为止Redis的，其名单看起来不错 - 我应该看什么好？

Answer 1

我认为Redis的列表是一个不错的选择。我会为每个观察者名单，虽然去 - 这样，你有O（1）阅读并RPUSH/LPOP写，当所有观察家都收到他们的事件自动从系统中消失。

可以减少通过只存储在每个列表的事件ID每一个观看所需的存储空间，不过那么你将需要保留一个计数器，每个事件，以确定它可以从系统中删除。

要与一个列表落实，建立具有每经过一个事件被添加到列表的头部时间的计数器。还为每个客户设置一个计数器，指示他们收到了多少事件。这些差异是您需要从列表中获得的项目数量。

这种方法的缺点是，新项目可以被添加到列表中，你检查柜台后。你可以通过从列表的尾部开始计算，但是这是O（N）而不是O（1）。您可以通过从列表中修剪接收到的事件来减少N，并且还可以为尾部位置维护一个计数器 - 工作的效果取决于观察者离线时可以累积的事件数量。

Answer 2

你可以看看它是如何在做Tarantool，用一个Lua程序，以保持一个环形缓冲区事件： https://github.com/mailru/tntlua/blob/master/notifications.lua