mongodb上设计一个高效的事件通知系统

想要实现一个类似segmentfault这样的通知系统。

现在有三个模型,一个是user,一个是article,一个是event。
user关注article之后,关于article的event就会有通知发送给所有关注它的user。

现在想到三种方案:
一个是article下做一个event的数组,user则有他关注的article的数组,每次读取通知的时候就查找所有关注的article,找出上次拉取通知之后发生的event。但是这样就要纪录上次拉取event的时间,并且比较event的时间,感觉读取性能有影响,但似乎也没有更好的解决方案了,不知道这是不是常用的方案。

还有一种方案和第一个方案差不多,但是是SQL数据库的样子,就是单独建一个event的表,保存event相关的article的id,然后读取通知的时候就搜索发生在上次读取通知事件之后的,并且article的id也在user关注列表中的事件。从心理上来说我不太喜欢这个方案,因为感觉这不是NoSQL的风格

另一个方案就比较无厘头了,article保存一个关注它的user的列表,user保存一个event的列表,每次关于一个article的event发生之后,就对所有在article关注列表里的user写入一个event的id,这样user每次拉取通知的话直接populate他的event列表即可。很显然关注数多了之后写入性能会很差,但是感觉整体逻辑非常清晰

大家给个建议,说说这个一个系统怎么实现比较好

如果我没理解错的话,我会会这样做:三个模型 user, article, notification

  1. 每一篇article里面都包含了一个数组:subscripters[],任何用户关注了当前的article就会把改用户的id加入到这个subscripters里面。

  2. 每一篇article在改动之后系统都会触发notification模型,该模型会读取当前article里面的全部subscripters任何创建推送数据。然后存储到notification数据库里面并伴随一个status:”pending”。

  3. 任何用户点击了被推送的信息,该条目在notification都会被改成status:”open”. 如果用户修改已读推送成为未读推送,还在改条目内改回status:”pending”

这样,任何人都可以关注任何文章一次,任何文章在变动之后都会被推送一次,任何用户都可以随时改变推送属性儿不用改变user跟article里面的任何数据。

一点儿拙见,仅供参考。

我的天,居然设计表还要考虑No不NoSQL……

我简单的说,User和Article的通知属性就不一样,在关系型数据库里好的设计是不同的通知存在不同的表里。而在MongoDB里,你完全可以实现一张表存储所有的通知,这还不够NoSQL吗?

表的设计是为需求服务的,不是为了感觉而设计的。

况且谁说NoSQL要和SQL划清界限,就不能你中有我,我中有你吗?

发表评论

电子邮件地址不会被公开。 必填项已用*标注