如何/最有效的方式向许多用户发送消息？
好的，我有一个有用户的网站。 我希望用户能够根据搜索查询向多个用户发送消息。
例如。 John搜索“佛罗里达”，此搜索返回 100 万个用户/公司。 让 john 向搜索结果返回的所有用户/公司发送消息的最佳方式是什么？
可以说，苏珊是这些用户之一。当她登录该网站时，她应该看到约翰发送的消息（因为苏珊在搜索返回的结果中）
（注意：这些消息是该网站的内部消息（不是电子邮件））
我有一个“消息”表，其中存储主要信息。
选项 1：是有一个参与者表来存储 message_id 和 user_id。然而，这需要对该表执行 100 万次插入。
选项2：？？？
关于最有效/最好的方法是什么的任何想法？
****编辑：澄清此内容的用法。****
这不是垃圾邮件。
该网站的工作方式类似于阿里巴巴网站，网站上的用户/公司希望显示内部消息。想法是，用户搜索某些内容，并根据该查询，他可以向搜索中出现的所有公司/用户发送消息，即购买线索请求
Ok so I have a site with users.
I want a user to be able to send a message to multiple users based on a search query.
Eg.
John searches for "Florida" and this search returns 1 million users/companies.
Whats the best way to let john send a message to all those users/companies returned by the search result?
Lets say, Susan was 1 of those users. When she logs into the site she should see the message which John sent (because Susan was in the results returned by the search)
(NB: the messages are internal to the site (not emails))
I have a "Message" table which stores the primary message.
Option 1: is to have a Participants table which stores the message_id and user_id. However this would require doing 1 million insertions into that table.
Option 2: ????
Any Ideas of whats the most efficient/best way to do this?
****EDIT: To clarify for the usage of this.****
It is not spam.
The site works like an Alibaba.com where the users/companies on the site, want to have the internal messages show up. The Idea is, a user searches for something, and based on that query, he can send a message to all the companies/users who show up in the search i.e a Buy Leads Request
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
USER_MESSAGES 表非常小 - 它是 MESSAGES 和 USERS（即收件人）之间的交集。这是两个外键列，也许还有一个状态。因此，尽管它可能有很多记录，但它们不会占用太多空间。您不必为每个收件人存储消息的实例。
所以存储绝对不是问题。性能可能是您关心的问题，但如今任何像样的数据库引擎都可以在不到一秒的时间内插入数千条记录。这只是优化集合操作而不是单个行的问题。
您始终可以选择整理表格。如果收件人删除“消息”，则会删除交叉记录。也许添加一个日期列，然后将在特定时间范围内未读取的“消息”超时实际上，这听起来像是一个积极的功能：鉴于您的业务模式，发件人可能希望及时回复，并且不会对三个月前的提议的回复感兴趣。
这完全取决于你对效率的定义。磁盘存储很便宜，但也相对较慢。RAM 速度很快，但相对昂贵（尽管几年后 SDD 会便宜）。那么你想优化什么？约翰发送邮件需要多长时间？苏珊阅读消息需要多长时间？您在配置中间层上花费了多少时间？
The USER_MESSAGES table is quite small - it's an intersection between MESSAGES and USERS (i.e. recipients). So that's two foreign key columns and perhaps a status. So although it might have lots of records they are not going to take up a lot of space. It's not as though you have to store an instance of the Message for each recipient.
So storage is definitely not an issue. Performance might be what concerns you, but these days any decent database engine can insert thousands of records in a fraction of a second. It's just a matter of optimizing for set operation rather than individual rows.
You always have the option of housekeeping the table. If the recipients delete the "message" zap the intersection record. Perhaps add a date column and then timeout "messages" which haven't been read in a certain timeframe. Actually that sounds like a positive feature: given your business model the sender presumably wants timely replies and won't be interested in responses to a proposition which is three months old.
It all depends on your definition of efficiency. Disk storage is cheap but also relatively slow. RAM is fast but relatively expensive (although SDD will be cheapish in a few years time). So what do you want to optimize? How long it takes John to send a mailshot? How long it takes Susan to read the message? How much you have to spend on hard drives? How much time you spend configuring your middle tier?
一种解决方案是创建用户组 - 根据您问题的位置 - 将消息发送到该组而不是每个人。要管理是否已读，您可以简单地使用“过去 x 天/周/任何时间向“佛罗里达”分组的消息”功能，该功能很容易实现。
这将节省您进行一百万次插入的时间。不幸的是，我不确定是否有更好的方法来管理收件箱，但我确信比我更有知识的人能够添加我的建议。
One solution would be to create user groups - based on location from your question - have the message sent to the group rather than each individual. To manage whether read or not, you could simply have a "Messages to group 'Florida' in past x days/weeks/whatever" feature which would be easy enough to implement.
That would save you having to make a million inserts. Unfortunately, I'm not sure of a better way to manage the inbox, but I'm sure that someone more knowledgeable than me will be able to add to what I've suggested.
这是邮件服务器的典型功能。所以..
A. 另一个解决方案是在后台使用真正的邮件系统/服务器。
这设置起来有点复杂（它要求站点上的每个用户和每个组在本地服务器上都有一个真实的电子邮件地址，仅在内部使用），并让邮件服务器处理发送到组的多条消息不管怎样
，想想你可能必须提供如下功能：消息已读、消息未读、消息标记（重要等）、消息删除。因此，我相信您无法避免每个用户每条消息都有一条记录。现在，让我们考虑一下数据库上的该表中到底可以有多少条消息。如果一个用户的收件箱中平均有 100 条消息（顺便说一句，这是一个巨大的消息，我们谈论的是平均值），这意味着（请参阅 APC 的响应）一个包含 2 列（整数）、500 万行的表，索引为用户身份。对于任何严肃的数据库来说这都不是问题。
B. 现在，如果您真的很关心性能，您可以使用哈希存储/数据库（仅用于消息），例如 Memcached、Tokio Cabinet、CouchDB、MongoDB 等。
This is a typical feature for a mail server. So..
A. Another solution would be to just use a real mail system/server in the background.
This is a little bit more complicated to setup (it would require that every user and every group on your site to have a real email address on your local server, that is only used internaly) and let the mail server handle multiple messages sent to groups, etc etc.
Anyway, think on the fact that you must probably provide features like: message read, message unread, message mark (as important, etc), message delete. So, i believe there is no way you can escape having one record per message per user. Now, let's think how many messages can really be in that table on the DB. If one user has, on average, 100 messages in his inbox (btw which is huge, we are speaking about an average), this would mean (see APC's response) a table with 2 columns (integers) having 5 milions rows, indexed on user_id. This is not an issue for any serious DB.
B. Now, if you are really really concerned on performance, you can use a hash storage/DB (only for messages) like Memcached, Tokio Cabinet, CouchDB, MongoDB etc.