注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

小葫芦君(汉斯的博客)

博客迁移到新博客:https://blog.ssxingshou.com

 
 
 

日志

 
 
关于我

小小葫芦商城,为您提供高品质的商品,一流的产品,一流的包装服务,一流的物流服务,放心购买

网易考拉推荐

分享网站群发站内信数据库表设计  

2011-12-15 17:38:17|  分类: 默认分类 |  标签: |举报 |字号 订阅

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

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

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

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

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

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


百万级用户量的站内信群发数据库设计

随着WEB2.0的发展,用户之间的信息交互也变得十分庞大,而且实时性要求越来越高。现在很多SNS网站和一部分CMS网站都广泛地应 用了站内信这一模块,这个看似简单的东西其实背后隐藏着很多需要设计师重视的设计细节,要做好这个“邮递员”是很不容易的。为什么这么说呢?下面我们就一 步步来探索设计一个百万级用户量的站内信群发数据库,看完以后你就会明白什么是真正可靠高效的“邮递员”。

1、几十——几百的用户量

这样的网站规模最小,可能是一个中小企业的CMS系统,面对这样的用户量,我们就不必要考虑短消息数据量太大的问题了,所以按照怎么方便怎么来的原 则,群发就每人复制一条消息数据,这样用户可以自己管理自己的消息,可以非常方便进行“已读、未读、删除”等操作。按照这个思路,我们的数据库设计如下:

表T_Message

1
2
3
4
5
6
Id            bigint      --消息ID
SenderId      bigint      --发送者ID
ReceiverId    bigint      --接收者ID
SendTime      datetime    --发送时间
ReadFlag      tinyint     --已读标志
MessageText   text        --消息正文
这样,我们接受自己的消息时只要做如下查询:
1
SELECT * FROM T_Message WHERE ReceiverId=myid
查询自己的未读消息只要做如下查询:
1
SELECT * FROM T_Message WHERE ReceiverId=myid and ReadFlag=0
这种方法很简单,可能是我们第一个想到的,对于这样的用户量的情况这样的设计确实也足够了。

 

2、几千——几万的用户量

用户量到了这样的级哦别,这个网站应该算是比较大了,笔者估计,可能是一个地区性的SNS网站。那么面对这样的用户量,我们又该如何来设计站内信群 发呢?上面第一种思路还行得通吗?应该这样说,如果勉强要用上面那种设计,也是可以的,只不过T_Message可能要考虑分区。但是,大家会不会觉得消 息正文复制那么多条对于这样的用户量来讲空间浪费太大,因为考虑到接收者一般是不修改消息正文的,所以我们可以让所有接收者共享一条消息正文。具体数据库 设计方法和上面大同小异:

T_Message

1
2
3
4
5
6
Id              bigint      --消息ID
SenderId        bigint      --发送者ID
ReceiverId      bigint      --接收者ID
SendTime        datetime    --发送时间
ReadFlag        tinyint     --已读标志
MessageTextId   bigint      --这里把消息正文内容换成消息正文Id
T_MessageText
1
2
3
Id              bigint      --ID标识
SenderId        bigint      --发送者ID
MessageText     text        --消息正文

这样,我们就大大节省了消息的存储空间,但是查询的时候就稍微麻烦一点,就需要进行联合查询了,查询自己的未读消息可以这样(意思一下,可能还有更高效的查询方式):

1
2
3
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

1
2
3
4
5
6
7
Id                  bigint      --消息ID
SenderId            bigint      --发送者ID
ReceiverId          bigint      --接收者ID,如果为原始群发消息则为-1
SendTime            datetime    --发送时间
ReadFlag            tinyint     --已读标志,如果为原始群发消息则统一为0未读
SourceMessageId     bigint      --如果为-1则为原始群发消息,其他则为原始消息id
MessageTextId       bigint      --这里把消息正文内容换成消息正文Id
T_MessageText与上面方法的一样。

当然,如果你的活跃用户达到100%,那这种方法相对前一种就没有优势了,但这种情况基本上不太可能,所以,笔者觉得这种方法来处理大用户量的消息群发还是可行的。

 

4、总结

本文只是大致阐述了实现的原理,很多细节都忽略没有考虑,纯粹一个设计想法而已,有兴趣的朋友可以去自己实践一下,另外,笔者对数据库也不是很精通,如果有哪里阐述错误的还请指出,让我们一起进步。

 

5、如果你喜欢设计和架构,你可能还会喜欢以下文章

Facebook和人人网的网站后台架构对比

facebook图片存储架构技术全解析

各大网站架构总结笔记

一步步构建大型网站架构

大型网站架构不得不考虑的10个问题

  评论这张
 
阅读(5361)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017