【问题标题】:How can handle thousands of requests per second using php and mysql?如何使用 php 和 mysql 处理每秒数千个请求?
【发布时间】:2017-03-12 20:09:16
【问题描述】:

我想使用 php 和 mysql 技术实现每秒可以处理数千个请求的 API。

我以前没有做过这种 API。如果您有执行类似任务的经验,请告诉我步骤是什么?

如何实现这种每秒可以处理数千个请求的 API?

如果你能用示例代码解释一下,我会很高兴。

提前感谢您的帮助。

【问题讨论】:

  • 您应该使用 PHP Laravel 框架构建您的网站,该框架专为大型项目、数据库中拥有数百万条记录和更多用户而设计。

标签: php mysql linux apache memcached


【解决方案1】:

你需要考虑几个因素,例如:

  1. 验证 API。您的 API 应该由经过授权和身份验证的有效用户调用

  2. 缓存 API 结果。您的 API 应该缓存 API 调用的结果。这将使您的 API 能够更快地处理请求,并且每秒能够处理更多请求。 Memcache可以用来缓存API调用的结果

  3. API 架构。与基于 SOAP 的 API 相比,RESTFul API 的开销更少。基于 SOAP 的 API 对身份验证有更好的支持。它们的结构也比 RESTFul API 更好。

  4. API 文档。您的 API 应该有详细的文档记录并且易于用户理解。

  5. API 范围。你的 API 应该有一个明确定义的范围。例如,它将作为公共 API 在 Internet 上使用,还是作为私有 API 在公司 Intranet 中使用。

  6. 设备支持。在设计您的 API 时,您应该牢记将使用您的 API 的设备。例如智能手机、桌面应用、基于浏览器的应用、服务器应用等

  7. API 输出格式。在设计 API 时,您应该牢记输出的格式。例如,输出将包含用户界面相关数据还是仅包含纯数据。一种流行的方法称为关注点分离 (https://en.wikipedia.org/wiki/Separation_of_concerns)。例如分离后端和前端逻辑。

  8. 速率限制和节流。您的 API 应实施速率限制和节流,以防止 API 的过度使用和误用。

  9. API 版本控制和向后兼容性。您的 API 应该经过仔细的版本控制。例如,如果您更新 API,那么新版本的 API 应该支持旧版本的 API 客户端。在所有 API 客户端都迁移到新版本的 API 之前,您的 API 应继续支持旧 API 客户端。

  10. API 定价和监控。应监控 API 的使用情况,以便了解谁在使用您的 API 以及如何使用它。您还可以向使用您的 API 的用户收费。

  11. 衡量成功的标准。您还应该决定使用哪个指标来衡量 API 的成功。例如,每秒 API 调用数或来自您的 API 的监控收入。在确定您的 API 是否成功时,也可以考虑开发活动,例如研究、文章发表、开源代码、参与在线论坛等。

  12. 所涉及的成本估算。您还应该计算开发和部署 API 的成本。例如,您需要多长时间才能生成 API 的可用版本。 API 需要多少开发时间等。

  13. 更新您的 API。您还应该决定更新 API 的频率。例如,应该多久添加一次新功能。您还应该记住 API 的向后兼容性,因此更新 API 不会对您的客户端产生负面影响。

【讨论】:

    【解决方案2】:

    很好的答案,我认为要记住的一件事是瓶颈在哪里。很多时候,瓶颈不是 API 服务器本身,而是持久层的数据访问模式。

    想想您如何访问您的数据。对于发布新项目,很多时候处理可能会延迟并与原始请求异步处理。例如,如果调整图像大小或发送电子邮件,您可以集成 RabmitMQ 或 SQS 来排队作业,稍后可以由工作人员处理。队列在缓冲工作方面非常有用,因此如果服务器出现故障,则只需排队等待重新上线即可处理。

    在查询方面,了解索引的工作原理以及数据的存储方式非常重要。有不同类型的索引,例如哈希表可以为您提供恒定的访问时间,但您不能使用哈希表执行范围查询。最简单的方法是,如果您有简单的分散式数据对象,这些数据对象通过可以存储在索引中的标识符进行查询。如果您的数据比较复杂,需要进行大量连接或聚合,那么您可以查看存储在 Redis 或 memcache 之类的东西中的预计算值。

    【讨论】:

      【解决方案3】:

      根据博文中描述的详细信息,您可能希望使用异步、无状态架构。所以请求不会阻塞资源并且可以更容易地扩展(听起来总是比实际做起来容易;))。

      在不知道这些服务器会连接哪些其他服务的情况下(这当然不会让事情变得更容易),我会选择 Elixir/Erlang 作为编程语言并使用 Phoenix 作为框架。

      您将获得一种强大的函数式语言,它带有许多出色的内置功能/模块(例如,mnesia、实时滚动/展开版本)并且可以很好地扩展(很好地利用服务器的所有内核)。

      如果您需要将请求排队到第二层服务器,AMQP 客户端/服务器(例如 RabbitMQ)可能是一个不错的选择(保存/存储服务器的请求)。

      如果它是无状态的,那工作得很好,以客户端询问一件事的形式,服务器响应一次并完成任务。如果您有很多请求,因为客户端每秒都要求更新,那么您最好切换到有状态连接并使用 WebSockets,以便服务器可以将更新推送回许多客户端并减少大量聊天/尖叫。

      所有这些文字都是从“高处看”的。最后,这取决于您要提供什么样的服务。因为这缩小了“合适的工具”的范围。我的建议是一种我认为不远的可能性(之前提到的 Node.js 也非常有效)。

      【讨论】:

        猜你喜欢
        • 2020-12-16
        • 2018-07-12
        • 2019-08-21
        • 2019-06-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-06-02
        • 2023-03-18
        相关资源
        最近更新 更多