寻找解决以下问题的存储解决方案,最好具有类似NoSQL的速度和可伸缩性:
- Not necessary to exactly keep the order in which the events arrive.
最好不要存储每个事件的多个副本(例如在每个观察者的单独存储中)。
- At their own pace (pull model)
- Preferably with a "get me the next chunk of unread events" API
- Each observer needs to read every event (eventually)
- No guarantees on how often they will pull the changes. It might be necessary to store lots of events before they are read.
在RDBMS中,您可能只需对事件进行顺序编号,并记住每个观察者的“最后读否”。在交换某些ACID以获得速度和可伸缩性的同时,是否有可能实现类似的东西?
到目前为止,红宝石和它的名单看起来不错-有什么更好的我应该看看吗?
发布于 2011-02-08 03:05:41
我认为Redis列表是个不错的选择。不过,我会为每个观察者提供一个列表--这样就可以让O(1)用RPUSH/LPOP读写,当所有观察者都收到它们时,事件就会自动从系统中消失。
您可以通过在每个列表中存储一个事件id来减少每个观察者所需的存储空间,但随后需要为每个事件保留一个计数器,以确定何时可以将其从系统中删除。
若要使用单个列表实现,请设置一个计数器,该计数器在每次将事件添加到列表头时递增。还为每个客户端设置一个计数器,指示他们收到了多少事件。它们之间的区别是您需要从列表中获取的项目数。
这种方法的缺点是可以在检查计数器后将新项添加到列表中。你可以从列表的尾部计数,但那是O(N)而不是O(1)。您可以通过从列表中削减接收到的事件并为尾部位置维护一个计数器来减少N--这将取决于当一个观察者离线时累积了多少个事件。
发布于 2012-02-23 20:59:41
您可以看看在Tarantool中是如何完成的,使用Lua过程来为事件保留一个环形缓冲区:https://github.com/mailru/tntlua/blob/master/notifications.lua
https://stackoverflow.com/questions/4896576
复制相似问题