当用户量在1万左右时，怎样设计表实现论坛群发消息？

[yekeyishuo]

目前需求是可以对系统中的用户进行单个发送，按角色发送，所有发送；
单个发送这个比较容易处理，一条信息对应一个用户保存数据库，但是对于按照角色发送和所有用户发送，这个时候再用一条信息对应一个用户还合适吗？如果用户量大的时候如何处理？

[K-dash]

补充我楼上的发言: 对全站用户发不值得的缘故还是因为尽管一些帐号尽管不是僵尸用户,但有些是已经不来这个应用了或N久不登陆,此后也可能不再登陆的那种 我的方案并非完美,比如它只是让消息表的增速减缓以及将消息落到了比较正确的用户群中 可是这个表的数据只能增加却不能删减,因为说删除消息吧当然就是标记为未读,UI上不列出来也罢,实际上数据库里还是只能增不能减,不然一旦删除的话,他下次登陆又拉了进来咋办... 这是缺点,但又不是全天下都像BAT那般用户量大是吧,中等规模的应用我想都可以接受这个现实的,而且必要时再按用户ID分一下表,压力就大大下降了对么

[linxisheng]

没有一个大佬出来说说吗？ 个人感觉分角色跟个人的设计方式不是一个好设计，非常不便于业务的扩展，今天是按角色，明天按地域呢？后天按性别？一个人除了角色的属性还会有很多属性，一个人的一个属性还能有多个表现（你可以是管理员也可以是程序员，谁说程序员就不能做管理员），当然你可以说系统就这样了，以后再说 我想了两种方式： 第一种就是一人一消息记录，后续可以从数据库优化（读写分离、分区表、分布式等等来做优化），还可以采用近期表与历史表的方式来做，近期表存最近3个月或者几个月的消息，后台建一个轮训任务跑把近期表的数据往历史表丢。 第二种就是搞个用户属性表、用户属性关联表[本表ID、属性ID、用户ID]、消息表[本表ID、消息内容、属性ID]、用户表 这样的方式，这样查询要关联的表多些，但是系统大量采用针对用户属性这种方式来发送的话，存储量跟查询效率会快很多，当然这种消息表也可以分近期表与历史表。

[linxisheng]

引用 21 楼 kk86868058 的回复:

补充我楼上的发言: 对全站用户发不值得的缘故还是因为尽管一些帐号尽管不是僵尸用户,但有些是已经不来这个应用了或N久不登陆,此后也可能不再登陆的那种 我的方案并非完美,比如它只是让消息表的增速减缓以及将消息落到了比较正确的用户群中 可是这个表的数据只能增加却不能删减,因为说删除消息吧当然就是标记为未读,UI上不列出来也罢,实际上数据库里还是只能增不能减,不然一旦删除的话,他下次登陆又拉了进来咋办... 这是缺点,但又不是全天下都像BAT那般用户量大是吧,中等规模的应用我想都可以接受这个现实的,而且必要时再按用户ID分一下表,压力就大大下降了对么

这个方案不能针对某些用户发送消息，这是很大的问题

[漫天雪_昆仑巅]

个人觉得如果不想存那么多多余的数据的话，就在之前“一条信息对应一个用户保存数据库”的基础上加一个类型字段，类型可以有 “个人用户”、“角色“，”部门“..... 等等一些列的类型，最后就是一条短信对应一个对象，至于这个对象具体的是什么，就根据类型字段来区分， 比如发一个短信给研发部的所有人，就可以记录为信息，研发部标识，短信类型(”部门短信“)

[业余草]

根据自己的需求和应用场景来做吧，1w的用户其实不多，真不多

[qq_29699379]

学习了，很厉害，佩服佩服

[我叫小菜菜]

引用 6 楼 yekeyishuo 的回复:

[quote=引用 5 楼 u010192842 的回复:] [quote=引用 4 楼 yekeyishuo 的回复:] [quote=引用 1 楼 u010192842 的回复:] 信息对应角色，用户读取的时候从角色信息中读取。

但是这样没办法标明用户是否读取了这条信息？[/quote] 如果还要记录是否读取的话，那就都发吧，毕竟要回写信息状态....[/quote] 一万个用户，都发肯定系统一下子就挂了吧？[/quote] 如果要每个人都要记录是否已读该消息，那肯定要每个用户一条记录。 现有要素： 用户id，角色id，消息id（消息id关联到消息内容）。 可以这样子设计： 首先 1.消息表<消息id，角色id，消息内容>。这里消息id，角色id为组合主键，即一个消息可以分给多个角色，一个角色可以有多条消息。 2.用户与消息关联表<用户id，消息id，是否已读>。用户登录后拉取未读消息，先找到各自的未读消息id列表A，然后根据列表A去消息表去消息内容。 群发消息： 其实就是根据角色给表2插入角色组内用户id，消息id和默认值未读。并不需要很多时间，使用异步和延迟操作，一个事务，多次insert而已，速度没有想象中的慢啦！ 关键是，所谓的“群发”操作，并不是主动建立1万个连接并推送给客户端，而是数据库操作。 对于客户端来说，隔1min主动查询一遍就可以获取最新的未读消息了。。。

[疯狂熊猫人]

数据库慢，不会使用NOSQL吗？Redis SSDB等开源软件应对百万级的数据就小意思，又不需要很大的开销，使用还简单，关键是性能也高。 使用一个Hash保存消息 ：key=Message，field=角色，value=消息 一个List保存一条消息对应的用户ID ：key=角色，member=用户ID 轻松解决，是不是so easy？

[yekeyishuo]

引用 27 楼 crazypandariy 的回复:

数据库慢，不会使用NOSQL吗？Redis SSDB等开源软件应对百万级的数据就小意思，又不需要很大的开销，使用还简单，关键是性能也高。 使用一个Hash保存消息 ：key=Message，field=角色，value=消息 一个List保存一条消息对应的用户ID ：key=角色，member=用户ID 轻松解决，是不是so easy？

目前用的是mysql

[昵称是可以中文吗]

引用 13 楼 yenange 的回复:

这种不应当称之为消息， 用公告更合适。 可建立一个专门的公告表。 公告人人可看， 但不必为每一个人创建一条记录。 但是必须建立一个专门的日志表。 如果某人有看公告， 则此日志表有记录。 没有看公告， 则日志表无记录。 定时对比用户、公告、与日志表记录即可。 如果当前用户没有看公告（日志表无记录）， 显示公告即可。 用户看了公告（点击了），则在日志表中添加一条记录。

定时对比用户、公告、与日志表记录即可？ 这里的定时对于有什么用？对比啥呢

[吉普赛的歌]

引用 29 楼 SCAUSCNU 的回复:

[quote=引用 13 楼 yenange 的回复:] 这种不应当称之为消息， 用公告更合适。 可建立一个专门的公告表。 公告人人可看， 但不必为每一个人创建一条记录。 但是必须建立一个专门的日志表。 如果某人有看公告， 则此日志表有记录。 没有看公告， 则日志表无记录。 定时对比用户、公告、与日志表记录即可。 如果当前用户没有看公告（日志表无记录）， 显示公告即可。 用户看了公告（点击了），则在日志表中添加一条记录。

定时对比用户、公告、与日志表记录即可？ 这里的定时对于有什么用？对比啥呢[/quote] 你都不是楼猪…… 定时对比， 其实就是定时在数据库查用户是否有没有看的公告， 如果有推送给用户， 没有就算了。 公告可以设置有效期， 如果超过有效期的， 没有看也不必推送了。

[琅琊山二当家]

引用 17 楼 三断笛的回复:

简单地 一个消息表，（消息ID，用户，角色，消息）三个字段 如果是按用户发，就写用户和消息字段 如果按角色发，就写角色和消息字段 读取消息时，同时匹配用户和消息。(用户=@usercode or 角色=@userrole)

很好设计的，。。。。

[QuinJC]

learning~

[muzi1314_]

关注。。。。。。。。。。。。。。。。。。。。

[zyz0602]

学习了，涨知识

[繁花尽流年]

为什么不考虑弄这样一张纯log表。 消息主题关联用户还是角色都可以消息内容只需要记录一次。 LOG表 <用户ID,消息ID> 用户登录时默认检索是否有需要提醒的消息，无论怎么关联，只需要检索在LOG里不存在用户ID，消息ID的对应记录即是未读状态。 用户点击阅读后，自动在LOG表插入一条对应记录，一张纯ID的log表也不会对服务器造成什么访问压力。

[junes06]

学习了。。。。。。

[巴拉莱卡]

一万条记录是小问题。。 省力的做法是在程序端的消息中，使用系统公告阅读回执的方法。。 一个消息，所有用户登陆的时候会查询对应的阅读回执，无阅读的置顶。。。这个几乎是最省系统开销的方法了，把段时间的大任务，分切到分时段的小任务上，而且产生的记录更独立，可以尽快的回收空间。 具体看系统本身的业务事件流程，如果要求消息的即时性，就会繁琐一些，你既然提出在库内处理，估计没有这方面的问题。

[gw6328]

信息可以存一条，但是还是建议用信息id与用户id对应一下。 不然会有很多需要考虑的，新用户来了，老用户删了？ 消息时间各种问题。 反正还是要对应一下，因为你可能要存用户什么时候读消息，什么时候操作消息，本来就要用一条记录来记，所以先写一条也是可以的。

[砸死牛顿的苹果]

支持13楼做法