多平台推送通知的基础设施建议

发布于 2024-11-09 22:47:51 字数 524 浏览 6 评论 0原文

我们计划将推送应用程序引入我们的移动应用程序(适用于 Android 手机和平板电脑、iPhone、iPad 和 Blackberry)。

每 15 分钟我们就会得到一组新数据。该数据存储在 MySQL 数据库中。然后,我们将检查该数据是否与用户的订阅相匹配(数据是基于位置的,因此用户会订阅一个或多个位置的通知)。然后,应通过各自平台的推送服务通知所有具有匹配数据的用户。

服务器容量不是问题。我们主要使用 PHP,并且更愿意继续使用它,但如果有必要,也愿意使用其他语言。

我的问题是:

  1. 您能给我有关服务器端使用的技术的建议吗?它应该能够很好地扩展(我预计跨平台会有大量订阅),理想情况下可以与常见的推送网关一起使用,并且足够快,可以在下一批数据进入之前处理所有通知。

  2. 我对传输速度感到担忧这些通知。假设我们有 500.000 个订阅,并且数据匹配率为 50%,这意味着我们需要在 15 分钟内推送 250.000 条通知。您有处理大量通知和推送通知的经验吗?

多谢, 标记。

we are planning to introduce push applications to our mobile apps (for Android phone and tablet, iPhone, iPad and Blackberry).

Every 15 minutes we get a new set of data. This data is stored in an MySQL databse. We would then check if this data matches the subscriptions of our users (data is location based, so a user would subscribe to notifications for one or more locations). All users with matching data should then be notified via the push service of their respective platform.

Server capacity is not a problem. We are mostly using PHP and would prefer to stay with it but are willing to go with other languages if necessary.

My questions are:

  1. Can you give me advice on the technology to use on the server side? It should scale really well (I expect lots of subscriptions across the platforms), ideally work with the common push gateways and be fast enough to handle all notifications before the next batch of data comes in.

  2. I have concerns regarding the delivery speed of those notifications. Let's say we have 500.000 subscriptions and the data matches to 50%, that would mean we would need to push 250.000 notifications in 15 minutes. Do you have any experience with high numbers and push notifications?

Thanks a lot,
Mark.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

仙女 2024-11-16 22:47:51

尽管 PHP 非常适合生成动态 Web 内容,但我觉得它缺少一些执行此类高性能后台操作的基本功能。我会选择支持多线程的语言(我个人的偏好是 C# 4.0,但这也取决于您的服务器平台)。

如果您有多线程支持,则可以编写从数据库加载数据的线程,并且在加载数据时让其他线程推送通知。确保您可以配置交易的每个部分使用的线程数量,以便您可以根据需要限制性能。

如果一台服务器无法完成这项工作,您可能需要考虑跨多台服务器对数据进行分区。我想最快的方法是将记录块分配给不同的服务器。

最后的建议是,获得一个可以模拟问题并进行压力测试的测试环境。在进行压力测试时,不要停留在 500.000 的目标数量上,而要继续推进到至少十倍。这对于提前发现软件的弱点会更加有效。此外,能够限制某些硬件参数(例如内存、磁盘 IO、网络 IO 和 CPU)也会非常有帮助。通过模拟其中任何一个的少量,您可以了解软件在某些条件下的行为方式。如果您在生产中遇到任何性能问题,这种经验将为您提供帮助,并将帮助您提出硬件要求。

Although PHP is great for generating dynamic web content, I feel it misses some essential features for doing high performance background operations like this. I'd go with a language that supports multi-threading (my personal preference would lead me to C# 4.0, but it depends on your server platform as well).

If you have multi-threading support, you can then write threads that load the data from the database and while it is being loaded have other threads push out notifications. Make sure you can configure how much threads are used for each part of the deal, so you can throttle performance as needed.

If one server can't do the job, you might want to look at partitioning your data across multiple servers. I'd imagine the quickest way to do this is to assign blocks of records to different servers.

One final word of advice, get a test environment where you can simulate your problem and do stress testing. While stress testing, don't stop at your target number of 500.000, but push on to at least ten times that. This will be much more effective in finding the weak spots of your software in advance. Also it would be very helpful to be able to throttle certain hardware parameters, like memorey, disk IO, network IO and CPU. By simulating having a low amount on any of these, you get a feel for how the software will behave in certain conditions. This experience will help you if you run into any performance issues in production and it will help you come up with hardware requirements.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文