GitHub 通知系统的设计猜想

刚刚注意到 github通知页 如果点击里面的每一条通知的时候,刷新这个列表页都会去除已读的通知,没看到在点击链接的时候触发什么单独清除通知的操作,直接把链接复制出来访问也会清通知,求见多识广的大牛来解答一下这种类似的通知系统的后端设计。

xcaptain
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 2
Summer

notifications 数据表里有类似的两个字段:

type - 通知类型,如:issues、pull 等
type_id - 通知类型对应的 ID

当用户访问时:

https://github.com/summerblue/laravel5-che...

在入口里做这样的逻辑:

  • 查看当前用户的 unread_notification_count 是否大于 0,否的话继续;
  • 大于 0 的话,检查 notifications 表是否存在 type = pull 并且 type_id=11,不存在继续;
  • 存在的话,删除此条数据,并把 unread_notification_count 减 1 ;

非常直接的逻辑,大家有没有更好的设计?

7年前 评论
xcaptain

@Summer 如果增加一个通知表,那么还得关联上对应的pull request表,issues表,因为在获取通知列表的时候要有标题,作者信息,最后回复人信息。而且每次访问一个pull request详情页都去判断这个地址是不是在用户的未读通知表中,性能太浪费了吧,大部分时候都不在通知表里面。

还要维护用户表中的未读通知数和通知表中记录数的一致性,通知表会有频繁的查询删除操作,而且很有可能通知列表页是只显示最近n条未读通知的,用mysql也不好限制通知表中的记录数。

其实我就是想问一下这种情况用redis存通知可不可以,感觉挺麻烦的。

7年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!