摘要：第一版设计需求单用户之间通信融合了用户反馈需求数据库设计内容和收发者存在一张表中表这里一条存两次，类似邮件服务。参考群发站内信的实现群发站内信的实现续两年后，再议站内信的实现百万级用户量的站内信群发数据库设计
第一版设计
需求 ：单用户之间通信（融合了用户反馈需求） 数据库设计：Message内容和收发者存在一张表中
message表：
这里一条Message存两次，类似邮件服务。
status:已读、未读、已删
每当发信者发消息时，就向数据库中写入两条数据，相当于推送式。
推送式：
优势：在用户量（百、千）和消息量较少时，数据库操作效率高，无需联表查询；
劣势：不适合群发，重复保存文本内容。
比方说，Message字段有100个汉字，占用200个字节，那么5万条，就占用200×50000=10000000个字节=10M。简单的一份站内信，就占用10M，这还让不让人活了。第二版设计
需求：增加*企业管理员*和*系统管理员*的通知功能，即特殊用户的一对多功能 数据库设计：两张表，message保存消息内容，messagelog保存关系
message表
type：private：单对单 、 public：企业通知、 global：系统通知；
from_id:保存了发信者的userid，因为信的发送者是固定的，和发送日期、信息内容一样是固有信息可以放在一起，若放在messagelog中冗余。
from_status：message在发送者处的状态。同样是三种。
messagelog表
单用户间发件处理：
发送邮件，插入message和messagelog表各一条记录。（推送式）
企业或者系统发件处理（通知）：
发送邮件，插入message一条记录，在用户读取收件箱时从message中拉取通知。（拉取shi）
拉取式：
优点：“不用一次性插入N条，且不会产生无效的记录”。只有活跃用户才保存收取通知的记录，发件后再未登录的用户不会保存。
缺点：联表查询，时间复杂度更高
显示一个用户的收件箱内容流程：
通过userid取到用户信息（所属企业id、注册时间）；
查询rec_id=userid的记录,取message_id和rec_status;
（处理通知）查询messagelog表中，符合条件(type=GLOBAL or (type=PUBLIC and company_id= user.company )) and create_time > user.registertime 这些notice，把这些notice和2中的message_id集取交集，非交集中的notice显示未读状态，其他信息按2中读取的rec_status显示。
以上还有messag可见有效期的简单处理，用户注册前的通知不可被用户收到；
其他1.考虑当用户的company字段变更时对之前那些收到的company通知处理,个人认为在转企时变更用户其他信息时，也把原company的通知也同步到用户的messagelog记录中；也可以不管那些未读的原comopany通知；也可以把已处理的原company通知从messagelog中删除。这个得看业务要求，而且转企这种请求很少发生。
2.考虑普通用户下的1->N，当N不大时，可仍然按单对单的推送式处理；N很大时，就按通知处理方法。
群发“站内信”的实现
群发“站内信”的实现（续）
两年后，再议“站内信”的实现
百万级用户量的站内信群发数据库设计
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/69088.html
摘要：第一版设计需求单用户之间通信融合了用户反馈需求数据库设计内容和收发者存在一张表中表这里一条存两次，类似邮件服务。参考群发站内信的实现群发站内信的实现续两年后，再议站内信的实现百万级用户量的站内信群发数据库设计 第一版设计 需求 ：单用户之间通信（融合了用户反馈需求） 数据库设计：Message内容和收发者存在一张表中 message表： 这里一条Message存两次，类似邮件服务。...
摘要：第一版设计需求单用户之间通信融合了用户反馈需求数据库设计内容和收发者存在一张表中表这里一条存两次，类似邮件服务。参考群发站内信的实现群发站内信的实现续两年后，再议站内信的实现百万级用户量的站内信群发数据库设计 第一版设计 需求 ：单用户之间通信（融合了用户反馈需求） 数据库设计：Message内容和收发者存在一张表中 message表： 这里一条Message存两次，类似邮件服务。...
摘要：也可以在凌晨系统不是那么繁忙的时候操作。总结一下少量用户设计简单，但浪费空间，冗余高中量用户设计较简单，对表的操作压力大大量用户这不是增加几个表能解决的问题 基本功能 点到点的消息传送： 用户给用户 管理员给用户 点到面的消息传送 管理员给用户群 少量用户（10-999） 对于用户非常少的情况，没有必要深入的考虑数据库的优化，采用简单的表设计： 如表message ...
摘要：也可以在凌晨系统不是那么繁忙的时候操作。总结一下少量用户设计简单，但浪费空间，冗余高中量用户设计较简单，对表的操作压力大大量用户这不是增加几个表能解决的问题 基本功能 点到点的消息传送： 用户给用户 管理员给用户 点到面的消息传送 管理员给用户群 少量用户（10-999） 对于用户非常少的情况，没有必要深入的考虑数据库的优化，采用简单的表设计： 如表message ...
摘要：客户端访问后端，确认是否有发送给自己的站内信，如有，播放消息提示音，并更改页面站内信未读数。登陆请求成功，服务器监听程序会以作为用户的连接标识。调用上述的服务将信息推送到服务器监听程序。 流程说明 使用 web-msg-sender 作为 服务器监听程序。 客户端（浏览器）通过websocket连接 服务器监听程序。 服务器应用程序（后端） 通过curl访问 服务器监听程序，将需...
阅读 1648·2021-09-27 13:35
阅读 1810·2021-09-09 09:33
阅读 3321·2019-08-30 14:16
阅读 2340·2019-08-30 10:52
阅读 744·2019-08-29 16:35
阅读 1287·2019-08-29 15:22
阅读 3530·2019-08-23 18:21
阅读 2967·2019-08-23 18:00
