关于站内信的开发思路

项目名称：

站内消息中心

项目需求：

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

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

用户量大约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表的数据量越来越大。后期我们可以考虑分表，考虑历史信息是否展示或保留。以上设计思路在百万级用户网站上实测可用，目前无问题。欢迎大家指出不足，以完善功能。