在很多网站系统（如CMS系统，SNS系统等），都有“站内信”的功能。
“站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存。而“站内信”是系统内的消息，说白了，“站内信”的实现，就是通过数据库插入记录来实现的。
“站内信”有两个基本功能。一：点到点的消息传送。用户给用户发送站内信；管理员给用户发送站内信。二：点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。点到点的消息传送很容易实现，本文不再详述。下面将根据不同的情况，来说说“站内信”的群发是如何实现的。
第一种情况，站内的用户是少量级别的。（几十到上百）
这种情况，由于用户的数量非常少，因此，没有必要过多的考虑数据库的优化，采用简单的表格，对系统的设计也来的简单，后期也比较容易维护，是典型的用空间换时间的做法。
数据库的设计如下：表名：Message
ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；Message：站内信内容；Statue：站内信的查看状态；PDate：站内信发送时间；
如果，某一个管理员要给所有人发站内信，则先遍历用户表，再按照用户表中的所有用户依次将站内信插入到Message表中。这样，如果有56个用户，则群发一条站内信要执行56个插入操作。这个理解上比较简单，比较耗损空间。
某一个用户登陆后，查看站内信的语句则为：
Select * FROM Message Where RecID=‘ID’ OR RecID=0
第二种情况，站内的用户中量级别的（上千到上万）。
如果还是按照第一种情况的思路。那发一条站内信的后果基本上就是后台崩溃了。因为，发一条站内信，得重复上千个插入记录，这还不是最主要的，关键是上千乃至上万条记录，Message字段的内容是一样的，而Message有大量的占用存储空间。比方说，Message字段有100个汉字，占用200个字节，那么5万条，就占用200×50000=10000000个字节=10M。简单的一份站内信，就占用10M，这还让不让人活了。
因此，将原先的表格拆分为两个表，将Message的主体放在一个表内，节省空间的占用
数据库的设计如下：
表名：Message
ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；MessageID：站内信编号；Statue：站内信的查看状态；
表名：MessageText
ID：编号；Message：站内信的内容；PDate：站内信发送时间；
在管理员发一封站内信的时候，执行两步操作。先在MessageText表中，插入站内信的内容。然后在Message表中给所有的用户插入一条记录，标识有一封站内信。
这样的设计，将重复的站内信的主体信息（站内信的内容，发送时间）放在一个表内，大量的节省存储空间。不过，在查询的时候，要比第一种情况来的复杂。
第三种情况，站内的用户是大量级的（上百万），并且活跃的用户只占其中的一部分。
大家都有这样的经历，某日看一个网站比较好，一时心情澎湃，就注册了一个用户。过了一段时间，由于种种原因，就忘记了注册时的用户名和密码，也就不再登陆了。那么这个用户就称为不活跃的。从实际来看，不活跃的用户占着不小的比例。
我们以注册用户2百万，其中活跃用户只占其中的10%。
就算是按照第二种的情况，发一封“站内信”，那得执行2百万个插入操作。但是其中的有效操作只有10%，因为另外的90%的用户可能永远都不会再登陆了。
在这种情况下，我们还得把思路换换。
数据库的设计和第二种情况一样：
表名：Message
ID：编号；SendID：发送者编号；RecID：接受者编号（如为0，则接受者为所有人）；MessageID：站内信编号；Statue：站内信的查看状态；
表名：MessageText
ID：编号；Message：站内信的内容；PDate：站内信发送时间；
管理员发站内信的时候，只在MessageText插入站内信的主体内容。Message里不插入记录。
那么，用户在登录以后，首先查询MessageText中的那些没有在Message中有记录的记录，表示是未读的站内信。在查阅站内信的内容时，再将相关的记录插入到Message中。
这个方法和第二种的比较起来。如果，活跃用户是100%。两者效率是一样的。而活跃用户的比例越低，越能体现第三种的优越来。只插入有效的记录，那些不活跃的，就不再占用空间了。
以上，是我对群发“站内信”的实现的想法。
href:http://www.cnblogs.com/grenet/archive/2010/03/08/1680655.html
百万级用户量的站内信群发数据库设计
随着WEB2.0的发展，用户之间的信息交互也变得十分庞大，而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应 用了站内信这一模块，这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节，要做好这个“邮递员”是很不容易的。为什么这么说呢？下面我们就一 步步来探索设计一个百万级用户量的站内信群发数据库，看完以后你就会明白什么是真正可靠高效的“邮递员”。
1、几十——几百的用户量
这样的网站规模最小，可能是一个中小企业的CMS系统，面对这样的用户量，我们就不必要考虑短消息数据量太大的问题了，所以按照怎么方便怎么来的原 则，群发就每人复制一条消息数据，这样用户可以自己管理自己的消息，可以非常方便进行“已读、未读、删除”等操作。按照这个思路，我们的数据库设计如下：
表T_Message
Id bigint --消息ID
SenderId bigint --发送者ID
ReceiverId bigint --接收者ID
SendTime datetime --发送时间
ReadFlag tinyint --已读标志
MessageText text --消息正文
这样，我们接受自己的消息时只要做如下查询：
SELECT * FROM T_Message WHERE ReceiverId=myid
查询自己的未读消息只要做如下查询：
SELECT * FROM T_Message WHERE ReceiverId=myid and ReadFlag=0
这种方法很简单，可能是我们第一个想到的，对于这样的用户量的情况这样的设计确实也足够了。
2、几千——几万的用户量
用户量到了这样的级哦别，这个网站应该算是比较大了，笔者估计，可能是一个地区性的SNS网站。那么面对这样的用户量，我们又该如何来设计站内信群 发呢？上面第一种思路还行得通吗？应该这样说，如果勉强要用上面那种设计，也是可以的，只不过T_Message可能要考虑分区。但是，大家会不会觉得消 息正文复制那么多条对于这样的用户量来讲空间浪费太大，因为考虑到接收者一般是不修改消息正文的，所以我们可以让所有接收者共享一条消息正文。具体数据库 设计方法和上面大同小异：
T_Message
Id bigint --消息ID
SenderId bigint --发送者ID
ReceiverId bigint --接收者ID
SendTime datetime --发送时间
ReadFlag tinyint --已读标志
MessageTextId bigint --这里把消息正文内容换成消息正文Id
T_MessageText
Id bigint --ID标识
SenderId bigint --发送者ID
MessageText text --消息正文
这样，我们就大大节省了消息的存储空间，但是查询的时候就稍微麻烦一点，就需要进行联合查询了，查询自己的未读消息可以这样（意思一下，可能还有更高效的查询方式）：
SELECT T_Message.*,T_MessageText.* FROM T_Message
INNER JOIN T_MessageText ON T_Message.MessageTextId=T_MessageText.Id
WHERE T_Message.ReceiverId=myid AND T_Message.ReadFlag=0
用这种方法除了正文我们不能随便删除外，用户还是可以自己管理自己的消息。
3、百万级大用户量
如果一个网站到了百万级的用户量了，那我不得不膜拜该网站和网站经营者了，因为经营这样的网站一直是笔者的梦想：）好了，回归正题，如果这样的系统 放你面前，让你设计一个站内信群发数据库，你该何去何从，总之，上面两种常规的办法肯定是行不通了的，因为庞大的数据量会让消息表撑爆，即使你分区也无济 于事。这时候作为一个系统架构师的你，可能不仅仅要从技术的角度去考虑这个问题，更要从用户实际情况去着手寻找解决问题的办法。这里，有一个概念叫“活跃 用户”，即经常登录网站的用户，相对于那些一时冲动注册而接下来又从来不登录的用户来说，活跃用户对网站的忠诚度很高，从商业的角度来讲，忠诚的客户享受 更高端的服务。
根据这个思路，我们来探索一种方法。假设网站有500万注册用户，其中活跃用户为60万（这个比例真很不错了），现在我们要对所有用户群发一封致谢信。还是上面两张表，首先我们可以先往消息表中插入一条群发标识为-1的 消息，这里我们用字段SourceMessageId（原始消息）来标识（-1为原始群发消息本身，其他则是原始消息id），这样其实群发的工作已经完成 了，用户可以看到这条公共的消息了。但是用户需要有消息的控制权，所以必须让每个用户拥有一条自己的消息。要达到这个目的，我们可以让用户登录时检查是否 已经拷贝原始消息，如果没有拷贝，则拷贝一份原始消息并插入消息表，群发标识为原始消息的id；如果已经存在原始消息的拷贝，则什么都不做。这样，我们就只要为这60万活跃用户消耗消息空间就可以了。具体数据库设计如下：
T_Message
Id bigint --消息ID
SenderId bigint --发送者ID
ReceiverId bigint --接收者ID，如果为原始群发消息则为-1
SendTime datetime --发送时间
ReadFlag tinyint --已读标志，如果为原始群发消息则统一为0未读
SourceMessageId bigint
一篇文章：
站内短信很常见，比如系统需要发消息给用户，用户登录之后可以看到这些消息。
Msg表，字段如下：
id int 自增长id
senderid int 外键关联发送者id
title varchar(128) 短信标题
content varchar(512) 短信内容
createTime datatime 发信时间
status tinyint 发件箱中的状态：0--普通；1--删除
一张user_has_msg表，字段如下：
id int
departmentid int 部门群发的时候外键关联部门id，可以为空
receverid int 外键关联收信人，可以为空
msgid int 外键关联短信息
status tinyint 收件箱状态：0--普通；1--删除
readStatus tinyint 阅读状态：0--未读；1--已读
这样设计是基于如下考虑的：
首先，msg表包含了发件箱所需要的所有信息，程序的时候写发件箱的时候可以只考虑操作一张数据库表。
第二，user_has_msg中，departmentid主要考虑的是存在大量的按照部门群发的可能，这样的话，群发给一个部门的时候之需要在两张表上个记录一条数据，而不需要在user_has_msg中记录该部门员工数条记录。
但是，后来这个方案被我自己和同事讨论后否决了，原因如下：
首先，departmentid的存在使得没有用户可以删除收件箱中的站内信，因为删除了，其他人的收件箱里也看不到。
第二，msg表不能保证显示完所有的发件箱所需要的数据，因为只有着一张表的是后读不出来收件人信息。
修改后的版本是：
将msg修改为只保纯粹的信息的表：
id int 自增长id
title varchar(128) 短信标题
content varchar(512) 短信内容
createTime datatime 发信时间
将user_has_msg修改为保存各种关系和状态的表：
id int
senderid int 外键关联发送者id
receverid int 外键关联收信人
msgid int 外键关联短信息
sendStatus tinyint 发件箱中的状态：0--普通；1--删除
receveStatus tinyint 收件箱状态：0--普通；1--删除
readStatus tinyint 阅读状态：0--未读；1--已读
进一步:http://blog.rexsong.com/?p=1202
http://www.nowamagic.net/librarys/veda/detail/431
http://www.cnblogs.com/hejiaquan/archive/2012/04/07/2435817.html
http://baiyuxiong.iteye.com/blog/876211
http://huoding.com/2012/09/28/174
---------------------------------
一篇文章：
NO1.给所有的用户‘真的’发送一个信息。
NO2.在用户登录时，获取程序的待办任务。
发布消息的并发不会太大，数据量大可以按时间分表，只关心近期的
也可以使用redis