寻找针对以下问题的存储解决方案，最好具有类似NoSQL的速度和可伸缩性：
事件。很多，每个事件的数据很少。这就是我们需要存储的内容。
最好不要存储每个事件的多个副本（就像在每个观察者的单独存储中一样）。
观察员。其中一些（＆lt; 50）他们需要阅读事件
按照自己的节奏（拉模型）
最好带一个＆＃34;给我下一块未读事件＆＃34; API
每个观察者都需要阅读每个事件（最终）
无法保证他们提取更改的频率。在阅读之前可能需要存储大量事件。
在RDBMS中，您可能只是按顺序对事件进行编号并记住＆＃34;最后一次读取否＃34;为每个观察者。是否有可能实现类似的东西，同时交易一些ACID以获得速度和速度。伸缩性？
到目前为止，Redis的列表看起来很好 - 我应该看看哪个更好？
答案 0 :(得分：2)
我认为Redis列表是一个不错的选择。我会为每个观察者提供一个列表 - 这样你就可以用RPUSH / LPOP读取和写入O（1），当所有观察者都收到它们时，事件会自动从系统中消失。
您可以通过在每个列表中存储事件ID来减少每个观察者所需的存储空间，但是您需要为每个事件保留一个计数器，以确定何时可以从系统中删除它。
要使用单个列表实现，请设置一个计数器，每次将事件添加到列表头部时，该计数器都会递增。还为每个客户设置一个计数器，指示他们收到了多少事件。它们之间的区别是您需要从列表中获取的项目数。
这种方法的缺点是，在检查计数器后，可以将新项目添加到列表中。您可以通过从列表尾部计算来解决这个问题，但这是O（N）而不是O（1）。您可以通过修剪列表中的已接收事件来减少N并维持尾部位置的计数器 - 其工作情况将取决于观察者离线时可累积的事件数量。
答案 1 :(得分：0)
你可以看看它是如何在Tarantool中完成的，使用Lua程序为事件保留环形缓冲区： https://github.com/mailru/tntlua/blob/master/notifications.lua