系统公告的设计思路

作者: wxfeng 分类: web前端 发布时间: 2021-09-09 15:27    阅读 25 次

功能描述

管理员通过后台可向全平台用户发送站内信,站内活跃用户可收到消息,非活跃用户(两年内未登录)不需要收到消息。

需求分析

从上诉需求可以分析,可以抽象出消息实体用来存放具体的消息内容,比如标题、内容、消息,类型发送时间。其次还需要有用户实体存放用户信息以及用户消息关联实体,存放消息和用户之间的关联,大致有用户id、消息id、阅读状态等。

设计思路

推模式与拉模式

一般获取消息的模式分为两种,既推(push)模式和拉(pull)模式。对于数据库表设计来说,也可以分为推、拉两种模式。

推模式:当管理员发送系统通知之后,遍历用户表写通知,相当于对每个用户都在通知表中保存了一份通知消息,在小规模系统上,是可行的,但是用户基数很大的话,会占用大量的存储空间,并且这些空间存储的内容几乎一样。

拉模式:当管理员发送系统通知之后,保存这条消息到通知表中,发布通知的流程就结束了。用户在登陆之后,附带上最近一次登录的时间戳,去请求服务端是否有新的系统通知,如果有,那么获取新通知,写入未读通知字段中,只要存在未读通知,通知图标右上角的小红点就提醒。

所以,对于系统通知这类需求,拉模式是再适合不过的了。根据用户规模在数据库设计时可以分为以下两个方案:

方案一:【适合活跃用户在5万左右】

公告「announce」表结构如下:

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //公告编号;
senderID: {type: ‘string’, required: true} //发送者编号,通常为系统管理员;
title: {type: ‘string’, required: true} //公告标题;
content: {type: ’text’, required: true} //公告内容;
createdAt: {type: ‘timestamp’, required: true} //发送时间;

用户公告表「notify_announce_user」表结构如下:

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号;
announceID: {type: ‘integer’} //公告编号;
recipientID: {type: ‘string’, required: true} //接收用户编号;
createdAt:{type: ‘timestamp’, required: true} //拉取公告时间;
state: {type: ‘integer’, required: true} //状态,已读|未读;
readAt:{type: ‘timestamp’, required: true} //阅读时间;

平台发布一则公告之后,当用户登录的时候去拉取站内公告并插入notify_announce_user表,这样那些很久都没登陆的用户就没必要插入了。「首次拉取,根据用户的注册时间;否则根据notify_announce_user.createdAt即上一次拉取的时间节点获取公告」

方案二:【适合活跃用户在百万-千万左右】

和方案一雷同,只是需要把notify_announce_user表进行哈希分表,需事先生成表:notify_announce_<hash(uid)>。
用户公告表「notify_announce_<hash(uid)>」 表结构如下:

id: {type: ‘integer’, primaryKey: true, autoIncrement:true} //用户公告编号;
announceID: {type: ‘integer’} //公告编号;
recipientID: {type: ‘string’, required: true} //接收用户编号;
createdAt:{type: ‘timestamp’, required: true} //拉取公告时间;
state: {type: ‘integer’, required: true} //状态,已读|未读;
readAt:{type: ‘timestamp’, required: true} //阅读时间;

如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作!

发表评论

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