专业建议：消息传递解决方案
我正在整理一个批量短信解决方案的应用程序。我可以轻松地使用 Java、Perl 或 PHP 编写应用程序。
请建议处理异步消息传送的最佳媒介。
我确实拥有网络凭据，即：
- IP
- 端口、
- 用户名、
- 密码
- 等
用于 SMPP 连接的
。我正在查看以下内容：
- 用户从网络上传 CSV 或 XLS 文件
- 数字和消息保存在数据库中
- 我创建一个 cron 来定期检查数据库中是否有排队等待发送的消息
- 要发送的消息被转发到active MQ（APACHE 的消息传递工具）。
- MQ 转发到网络
- MQ 从网络接收确认和传送状态并更新数据库。
请指出我的想法是否步入正轨或者是否有更好的解决方案。
I am putting together an application for a bulk SMS solution. I am comfortable writing the application in Java, Perl or PHP.
Kindly advise on the best medium to handle asynchronous messaging delivery.
I do have credentials with the networks i.e:
- IP
- Port
- Username
- Password
- etc
for SMPP connectivity.
I am looking at the following:
- User upload a CSV or XLS file from the web
- The numbers and messages are saved in a database
- I create a cron to check database periodically for messages that are queued to be sent
- Messages to be sent are forwarded to an active MQ (A messaging tool by APACHE).
- MQ forward to the network
- MQ receives acknowledgement and delivery status from network and update the database.
Kindly point out if my concept is on track or if there is a better solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实上，您正在谈论 SMS 消息（这是一个异步消息处理系统），这让事情有点混乱 - 实际上这并不重要 - 重要的是您正在尝试编写一个异步消息处理系统来执行某事。
用于排队和处理消息的现成解决方案层出不穷。以前我曾使用 BSD lpd 处理少量短信/传真。您同样可以使用 MTA 或专门为 SMS 处理设计的工具，例如 Kannel。 IME，处理提供多个不同 API 的聚合器，事实证明推出我自己的解决方案更有效。
如果您要编写自己的解决方案，请不要使用 cron。
当您的 cron 作业启动时，您是否只接收一条消息并处理它？您是否尝试获取所有可用的消息并处理它们？如果这花费的时间超过了 cron 作业之间的间隔怎么办？虽然消息传递子系统（在订阅者之前 - 不是之后）会消除一些复杂性，但它并不能解决所有问题。
执行此操作的正确方法是使用守护进程作为单线程运行或按计划分片运行。
The fact that you are talking about SMS messages (which is an asynchronous message hanldling system) confuses things a little - in practice it doesn't matter - the important thing is that you are trying to write a asynchronous message handling system to do something.
There are no end of ready made solutions for queueing and processing messages. Previously I've used the BSD lpd for low volumes of SMS/fax. You could equally use an MTA, or a tool specifically designed for SMS handling such as Kannel. IME, dealing with aggregators providing multiple different APIs it proved more effective to roll my own solution.
If you are going to write your own solution, don't use cron.
When your cron job fires, do you only pick up one message and process it? Do you try to pick up all the available messages and process them? What if that takes more than the interval between the cron jobs? While the messaging subsystem (BEFORE your subscriber - NOT after) would take some of the complexity out of this, but it doesn't solve all the problems.
The right way to do this is with a daemon process either running as a single thread or with planned sharding.