设计篇--站内信设计思路之己见（基于上百万用户）

大家都知道站内信，分为少量（10-999用户），中量（1000-99999用户），大量（100W用户）不同的站内信架构，消耗存储空间，和效率也是不同的。

本人基于最大的架构，来于大家共同讨论，站内信这个小功能，究竟要怎么设计，才能更节约空间。下面是基于我个人的一些见解：

站内信的功能是：

1、用户与用户之间的交流，像邮件形式。

2、管理员给用户发站内信。

3、管理员群发消息给所有的用户（对于100W用户，你要怎么做？）

 

开门见山,先看看我设计的数据库表关系：

Message表：

MessageID：标识列；  SendId：发件人id；  RecId：收件人id；  TextId：消息id；  Status：标识已读1/未读0；

MessageText表：

TextId：标识列；  Titel：标题；  Text：信件内容；  Time：发件时间；

SysMessag表:

SysID:标识列；  CustomerID：用户标识列；  MessageID：消息标识列；  SysStatus：系统消息已读1/未读0；

一个用户需要接收多条系统信息，而每条系统信息则会有一个对应的消息状态，所以这张表是对应没条系统消息的一个状态的判断。

所有标识列都是主键

三张表关系就是这样子：

表设计就是这个样子，用到三张表。

现在需要来检验我的设计的时候了，假如，管理员给所用户群发消息的发送id=0也就是RecId = 0

我需要在Message表中插入一条记录，格式如同这样子：

这条系统消息已经记录在数据库中

现在用户都读不到这条信息，现在模拟，假如有一个用户登陆了帐号，接下来要做的就是：

　　1、首先读取Recid中有没有与该用户Id匹配的消息，目前结果是没有；

　　2、之后再匹配RecId=0的系统消息数量，现在有一条，MessageID=1；

　　3、然后就对系统消息表SysMessag 插入现有的一条记录插入之后，也就像下面这样：

　　　　

　　　　SysStatus状态默认为未读0。

　　4、如果有多条信息的话，就执行多条插入操作，（什么？会有很多系统消息？  你见过系统消息有上百条？就算有上百条，数据执行100次插入 我想问题也不大吧？ - -||）

　　5、最后取消息的总数Message+SysMessag，反馈给前台，现在是1。

模拟到此结束。     o(∩_∩)o

用户已读系统消息只能修改存于SysMessag 中的SysStatus的状态，不能去修改Message表中的状态，我想这个是可控的。

（什么？你说用户发消息的时候输入RecId=0？这个权限问题你不能控制？ 那我真不知道说什么好了。^_^ ）

有100W的用户现在只会依据活跃用户而占用存储空间，而不活跃的用户，根本不用再去为浪费的存储空间而烦恼了。

看完之后，想必大家对站内信设计，也有自己的看法观点，欢迎评价，提出您宝贵的意见，让我学到更多考虑问题的角度，谢谢

 

转载请注明出处，这是对作者写的文章的肯定和支持，谢谢。