关于站内信的开发思路

项目名称：

站内消息中心

项目需求：

运营人员可以向单个或多个用户推送消息；

系统可自动给单个用户推送消息（如：订单已发货状态，自动给用户推送已发货相关状态）；

用户量大约50万；

程序设计思路：

网站50万用户中，活跃用户只占一小部分，所以没有必要直接把消息数据插入到用户消息表。采取用户登录后，主动拉取消息的形式，保证只有活跃用户的消息，才保存至消息表中，防止大量的冗余数据的产生。

表的设计，三张表，

1. 消息表（message_info），存储消息本身内容。结构如下

message_info_id 消息表主键，自增

title 消息标题（因自身业务需求，标题单独存）

text 消息内容

message_url 消息跳转url（因自身业务需求，消息跳转url，可为空）

push_time 消息推送时间（用户收到消息的时间，时间戳）

operator 消息创建人id（因自身业务需求，创建消息的运营人员的id身份）

operator_nick 消息创建人昵称（因自身业务需求，创建消息的运营人员的昵称）

type 消息类型（因自身业务需求，按消息接收人数区分，private私信，group 100人以内组消息，public 100人以上公共消息，global 全员消息）

s_num 成功发送消息人数（自身业务需求）

f_num 发送失败的人数（自身业务需求）

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2.消息&用户关系表（message_user）（发送的消息id与接收的用户id关系表）

message_user_id 主键，自增

user_id 用户ID（用户的唯一标识）

message_info_id 上方消息表的主键（消息唯一标识）

status 是否删除（删除状态位）

3.消息拉取表（用户&&消息落地表）

message_send_id 主键，自增

user_id 用户ID（用户唯一标识）

message_info_id 消息表ID（消息唯一标识）

message_title 消息标题

message_text 消息内容

message_url 消息跳转url

status 已读OR未读

type 消息类型

push_time 消息收到时间

is_del 删除状态位

以上三张数据表，完全是根据自身的业务需求制定，其中部分字段非必须，可根据自身需求调整。

当系统或运营人员想给单个or多个用户推送消息时。首先，生成一条消息信息，插入到message_info表，并生成一个对应的消息ID。然后将此消息ID与接收消息的uid组成一条信息，插入message_user表中，状态位status默认为0 。如多个用户收到此消息，多少个用户，就插入多少条信息。这样，就把大量的信息都存在了message_user表中，也就是消息&用户表，可给此表建立联合唯一索引（message_info_id，user_id），虽然此表数据量可能巨大，但此表的主要用途就是查询消息和用户的关系，并且建立有索引，所以不太用担心效率问题。

当一个用户登录后，首先查询message_user 表，以用户UID为条件，select message_info_if frommessage_user where user_id=用户id and status=0；查询出与此用户对应关系的消息id，如有数据，拿此message_info_id去message_info表中查询出此条消息的内容select * from message_info where message_info_id=消息id and push_time <= 当前时间；注意条件，推送时间小于等于当前时间；把结果组合用户id，插入到message_send表中，status默认为0未读，is_del为0未删除（插入之前，判断一下message_send表中是否已经存在此条消息，判断一下message_send表中是否存在user_id=用户id and message_info_id=消息id，如果不存在才插入）；至此，此用户所有的消息，都被拉取至message_send表中。用户的消息列表页，我们只需查询message_send表中的is_del=0的信息即可。如用户阅读或删除了某条消息，只需更新message_send表中的status和is_del状态即可。

当然，此方式短期内没问题，但时间久了之后，会导致message_user表的数据量越来越大。后期我们可以考虑分表，考虑历史信息是否展示或保留。以上设计思路在百万级用户网站上实测可用，目前无问题。欢迎大家指出不足，以完善功能。

关于站内信的开发思路相关推荐

单系统站内信数据库设计思路
第一版设计需求 :单用户之间通信(融合了用户反馈需求) 数据库设计:Message内容和收发者存在一张表中 message表: 这里一条Message存两次,类似邮件服务. status:已读.未读 ...
ASP.NET 实现站内信功能（点对点发送，管理员群发）
正好这段时间在研究这个功能,还是得感谢这位大神,没有他的引路,我就不可能把站内信做出来. http://www.cnblogs.com/grenet/archive/2010/03/08/168065 ...
单系统站内信设计概述（满足百万级信息）
基本功能点到点的消息传送: 用户给用户管理员给用户点到面的消息传送管理员给用户群少量用户(10-999) 对于用户非常少的情况,没有必要深入的考虑数据库的优化,采用简单的表设计: 如表mes ...
mysql群发消息_百万级用户量的站内信群发数据库设计
随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高.现在很多SNS网站和一部分CMS网站都广泛地应用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的 ...
mysql群发消息_分享网站群发站内信数据库表设计
本文和大家分享一下网站站内信实现表设计的功能.需要的朋友可以参考下. "站内信"不同于电子邮件,电子邮件通过专门的邮件服务器发送.保存.而"站内信"是系统内的消 ...
网站系统群发“站内信”的实现
在很多网站系统(如CMS系统,SNS系统等),都有"站内信"的功能. "站内信"不同于电子邮件,电子邮件通过专门的邮件服务器发送.保存.而"站内信&q ...
两年后，再议“站内信”的实现
两年前,万仓一黍在博客园发了两篇关于站内信的设计实现博文,<群发"站内信"的实现>.<群发"站内信"的实现(续)>,其中阐述了他关于站内 ...
基于百万级别的站内信设计
基本上现在的网站都会有站内信功能,主要分为少量(10-999用户),中量(1000-99999用户),大量(100W用户)不同的站内信架构,消耗存储空间,和效率也是不同的.这次要设计的是基于百万级别的 ...
解读周源站内信，双重上市后知乎怎么走？
4月22日,美股上市公司知乎正式在港交所挂牌上市,股票代码为"2390".知乎也由此成为首家以双重主要上市方式回港的中概互联网公司. 伴随知乎的双重上市,创始人周源发布站内信表示, ...
网站群发站内信数据库表设计
"站内信"不同于电子邮件,电子邮件通过专门的邮件服务器发送.保存.而"站内信"是系统内的消息,说白了,"站内信"的实现,就是通过数据库插入记 ...

关于站内信的开发思路

关于站内信的开发思路相关推荐

最新文章

热门文章