zoukankan      html  css  js  c++  java
  • 群发“站内信”的实现(续)

      前几日,发布了博客“群发“站内信”的实现”,得到广大网友呼应,在此表示感谢。

      看了网友的留言。发现大家对文中的前两种情况没有什么异议,对第三种方案争议颇多。我在此再把我的第三种情况详细的阐述一下,和大家交流。另外,本文的主体主要放在“群发”(也就是点到面),至于“单发”(点到点),不在本文的讨论之列。

      先看看,第三种情况。站内的用户是大量级的(上百万)。

      经过考虑,表设计修正如下

      表名:Message

      ID:编号;RecID:接受者编号;MessageID:站内信编号;Statue:站内信的查看状态;

      表名:MessageText 

      ID:编号;SendID:发送者编号;Message:站内信的内容;PDate:站内信发送时间;

      这样,管理员(假设ID=1)给所有的用户发一封站内信。就在MessageText表中插入一条记录。例如:

      ID:4;SendID=1;Message=Good;PDate:2010-4-9

      某个用户(假设ID=7),登陆系统后,发现在MessageText的表中,有ID=4的记录,并且在Message中没有RecID=7且MessageID=4的记录,说明这条记录这个用户没有读过,给个提示信息给用户,提示用户看站内信。注意,此时仍然没有在Message中插入记录。一旦该用户点击查看该站内信的时候,在Message中插入一条记录,如:

      ID:55;RecID=7;MessageID=4;Statue=已读

      如果该用户删除这条站内信,则实际上是修改上面这条记录:

      ID:55;RecID=7;MessageID=4;Statue=删除

      这样一来,这个用户下次登陆的时候,由于Message表中有相应的记录,也不会提示用户看站内信。

      有网友质疑,为何删除的时候,只是标记“删除”,这样,长此以往,不是浪费大量的空间吗?这个网友说的也有道理。不过,我们还是要分析具体的情况。

      当网站的用户达到百万级的时候,其中的“活跃用户”(参看上文的介绍)可能只占其中的一小部分。

      假设,网站用户200万,其中活跃用户40万。

      一封站内信,在MessageText中有一条记录,40万活跃用户都看了站内信(其实,这也不大可能,有不少的人是不看站内信的)。在Message中插入了40万条记录。以后,不管是阅读或者是删除,在Message中保留了这40万条记录。

      好,如果不采用这种办法,在群发的时候,往Message中插入200万记录,40万活跃用户都看了信,并且都勤快的删除了站内信(这是不大可能的),Message中还是保留了160万条记录。因为,这些不活跃的用户可能永远都不会登陆了。那40万条记录(最坏的情况,因为如果有人不看站内信,就不会生成记录)和160万条记录(最好的情况,因为不是每个用户都会删除站内信。)相比,那个更加节省空间呢?

      站内信的设计,要根据你的受众群的具体情况而定,如果你的受众群活跃度接近100%,并且每人都很勤快,我的设计当然有问题。可实际中这个理想状态几乎是不可能出现的。

      

      有网友提出,如果站内信的对象不是全体而是一部分呢?抱歉,这个也不在本文讨论之列,你可以对我的表进行扩展,以达到你的要求。

      感谢各位网友的交流。我在此想说的是,我们设计一个系统,必须得结合实际情况,根据实际情况来制定,比能达到一个比较理想的状况。

  • 相关阅读:
    Redis 发布/订阅模式
    Task
    并发入门
    ThreadPool线程池
    C# 5.0 CallerMemberName CallerFilePath CallerLineNumber获取调用方法名称,路径,行号
    信号量
    互斥体
    锁机制
    .net remoting(1)简单例子
    C#并行编程-并发集合
  • 原文地址:https://www.cnblogs.com/grenet/p/1708008.html
Copyright © 2011-2022 走看看