“站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存。而“站内信”是系统内的消息，说白了，“站内信”的实现，就是通过数据库插入记录来实现的。

“站内信”有两个基本功能。一：点到点的消息传送。用户给用户发送站内信；管理员给用户发送站内信。二：点到面的消息传送。管理员给用户(指定满足某一 条件的用户群)群发消息。点到点的消息传送很容易实现，本文不再详述。下面将根据不同的情况，来说说“站内信”的群发是如何实现的。

第一种情况，站内的用户是少量级别的。(几十到上百)

这种情况，由于用户的数量非常少，因此，没有必要过多的考虑数据库的优化，采用简单的表格，对系统的设计也来的简单，后期也比较容易维护，是典型的用空间换时间的做法。

数据库的设计如下：表名：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%。两者效率是一样的。而活跃用户的比例越低，越能体现第三种的优越来。只插入有效的记录，那些不活跃的，就不再占用空间了。

以上，是我对群发“站内信”的实现的想法。

1. 方案描述

该方案用于系统站内信功能模块在百万级用户量情况下的效率问题，只是后台管理员给前台用户发送站内信，用户与用户之间的发送不在讨论内。

2. 方案详情

假设系统的用户量达到了200W，活跃用户为10W，系统后台管理员要给全体用户发送一条感谢信，如果按照之前的存储方式，消息队列需要插入200W条数据，可是除了活跃的10W用户，其他用户都忘了自己有该网站的账号，他都有可能不再登陆该网站了，数据库保存的消息队列无意义了。

现表结构如下：

消息表编号ID    NUMBER标题TITLE    VARCHAR2(50)    50正文CONTENTS    VARCHAR2(1000)发送状态STATUS    NUMBER发送日期SEND_DATE    DATE发送方式SEND_TYPE    NUMBER最新创建人FCU

VARCHAR2(50)    50更新人LCU    VARCHAR2(50)    50创建时间FCD    DATE最新更新时间LCD    DATE删除标记DELETE_TAG

CHAR(1)    1

消息容器编号ID    NUMBER站内信ID

MESSAGE_ID    NUMBER收件人ID

MEMBER_ID    NUMBER是否已读READ_STATUS    NUMBER

会员表

主键id    NUMBER会员编号u_number    NUMBER电子邮箱u_email

VARCHAR2(200)    200密码u_passwd    VARCHAR2(50)    50企业认证company_admit

NUMBER(1)    1帐号禁用帐号禁用NUMBER(1)    1创建人FCU    NUMBER最后更新人LCU    NUMBER首次创建时间FCD    DATE最后更新时间LCD    DATE删除标记DETELE_TAG

char(1)    1

在尽量不改变表结构的前提下，改变一下程序写数据库的方式：

后台管理员发送一条站内信，接收对象为全体会员，系统往站内信表插入一条站内信，其中发送方式区分接收的对象(0为全体发送，1为只发送给注册会员，2为只发送给企业会员，3为指定会员发送)，这样，发送给全体会员的一条站内信暂时只生成了一条数据。

前台会员登陆的时候，根据会员自身的会员类型(普通会员，企业会员)查询站内信表中属于自己的最新消息(根据自己所持消息的最新时间与消息表的发送时间做 比对)，往消息容器中插入自身与所持消息的关联数据，默认未未读，在前台会员点击某一条未读站内信的时候，将容器中的对应站内信状态改为已读。

如果后台管理员只指定发送站内信给某几个会员，则往站内信表插入一条站内信后，将这几个会员与该站内信的关联直接往消息容器中写关联，不需要前台会员取。

另：因为改变了发送接收方式，后台管理员只指定发送站内信给某几个会员，但是站内信状态未未发送，只是保存草稿，需要往站内信主表增加一个字段，保存指定会员的id串，用于关联此草稿与指定会员的关联，此处就要求发送给指定会员的数量不能太多，需要限制。

这样，百万级用户量的系统，活跃度为10%的用户登陆系统，只生成了10W的数据，用户活跃度越低，此方案效率越明显，如果是100%活跃度的话，此方案和现有方法无区别。