大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
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、如果你喜欢设计和架构，你可能还会喜欢以下文章
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/167344.html原文链接：https://javaforall.net
![ElasticSearch索引基本查询语法[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
