站内信

Posted antball

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了站内信相关的知识,希望对你有一定的参考价值。

http://daihaixiang.blog.163.com/blog/static/3830134201111155381735/

如果一个网站到了百万级的用户量了,那我不得不膜拜该网站和网站经营者了,因为经营这样的网站一直是笔者的梦想:)好了,回归正题,如果这样的系统 放你面前,让你设计一个站内信群发数据库,你该何去何从,总之,上面两种常规的办法肯定是行不通了的,因为庞大的数据量会让消息表撑爆,即使你分区也无济 于事。这时候作为一个系统架构师的你,可能不仅仅要从技术的角度去考虑这个问题,更要从用户实际情况去着手寻找解决问题的办法。这里,有一个概念叫“活跃 用户”,即经常登录网站的用户,相对于那些一时冲动注册而接下来又从来不登录的用户来说,活跃用户对网站的忠诚度很高,从商业的角度来讲,忠诚的客户享受 更高端的服务。

根据这个思路,我们来探索一种方法。假设网站有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个问题

以上是关于站内信的主要内容,如果未能解决你的问题,请参考以下文章

站内信

视频学习笔录---ThinkPHP---thinkphp完善站内信功能

新增站内信功能,支持通过VS Code直连Linux-SSH协议资产,JumpServer堡垒机v2.11.0发布

新增站内信功能,支持通过VS Code直连Linux-SSH协议资产,JumpServer堡垒机v2.11.0发布

实现站内信和评论服务

观察者模式和发布订阅模式