我想使用php和mysql技术实现一个API，每秒可以处理数千个请求。
我以前没有做过这种API。如果你有实施类似任务的经验，你能告诉我步骤是什么吗?
我如何实现这种API，可以处理每秒数千个请求?
如果您能提供示例代码，我将很高兴。
提前感谢你的帮助。
根据文章中描述的细节，您可能希望使用异步的、无状态的体系结构。所以请求不会阻塞资源，并且可以更容易地扩展(总是听起来比实际做起来容易;))。
如果不知道这些服务器将连接到哪些其他服务(这肯定不会使事情变得更容易)，我将使用Elixir/Erlang作为编程语言，并使用Phoenix作为框架。
你得到了一个强大的函数式语言，它有很多很棒的内置功能/模块(例如记忆记忆，滚动/展开版本，而活)和可伸缩性好(很好地利用你的服务器的所有核心)。
如果你需要将请求排队到第二层服务器，AMQP客户端/服务器(例如RabbitMQ)可能是一个不错的选择(为服务器保存/存储请求)
如果它是无状态的，以客户端请求一件事，服务器响应一次并完成任务的形式工作得很好。如果你有很多请求，因为客户端每秒钟都会请求更新，那么你最好切换到有状态连接并使用WebSockets，这样服务器就可以将更新推送给很多客户端，从而减少很多喋喋不休/尖叫。
所有这些都是从"高视角"写的。最后，这取决于你想提供什么样的服务。因为这缩小了"合适工具"的范围。我的建议是一种可能性，我认为这并不遥远(前面提到的Node.js也比有效)。
你需要考虑以下几个因素:
-
正在验证API。您的API应该由经过授权和验证的有效用户调用
-
缓存API结果。您的API应该缓存API调用的结果。这将允许您的API更快地处理请求，并且每秒可以处理更多请求。Memcache可以用来缓存API调用的结果
-
API架构。与基于SOAP的api相比，RESTFul api的开销更小。基于SOAP的api对身份验证有更好的支持。它们也比RESTFul api更结构化。
-
API文档。你的API应该有良好的文档记录，并且易于用户理解。
-
API范围。你的API应该有一个定义良好的作用域。例如，它将在互联网上作为公共API使用，还是将在企业内部网内作为私有API使用。
-
设备支持。在设计API时，您应该记住将使用您的API的设备。例如智能手机、桌面应用、浏览器应用、服务器应用等
-
API输出格式。在设计API时，您应该记住输出的格式。例如，输出是否包含用户界面相关数据或仅包含普通数据。一种流行的方法是关注点分离(https://en.wikipedia.org/wiki/Separation_of_concerns)。例如分离后端和前端逻辑
-
速率限制和节流。你的API应该实现速率限制和节流，以防止API的过度使用和误用。
-
API版本和向后兼容性。您的API应该仔细地进行版本控制。例如，如果您更新了API，那么新版本的API应该支持旧版本的API客户端。你的API应该继续支持旧的API客户端，直到所有的API客户端都迁移到你的API的新版本。
-
API定价和监控。应该监视API的使用情况，这样您就可以知道谁在使用您的API以及如何使用它。你也可以向使用你API的用户收费。
-
成功的度量。您还应该决定使用哪个指标来衡量API的成功。例如，每秒调用API的次数或API的监控收益。开发活动，如研究、发表文章、开源代码、参与在线论坛等，在决定API的成功时也可能被考虑在内。
-
成本估算。您还应该计算开发和部署API的成本。例如，您需要花费多少时间来生成一个可用的API版本。API的开发时间等
-
更新你的API。您还应该决定更新API的频率。例如，应该多久添加一次新功能。您还应该记住API的向后兼容性，因此更新API不会对您的客户端产生负面影响。
回答得好，我认为有一件事要记住，那就是瓶颈在哪里。很多时候，瓶颈不是API服务器本身，而是带有持久层的数据访问模式。
想想你如何访问你的数据。对于发布新条目，很多时候可以延迟处理，并对原始请求进行异步处理。例如，如果调整图像大小或发送电子邮件，您可以集成RabmitMQ或SQS来为作业排队，稍后由工作人员处理。队列在缓冲工作中是很好的，所以如果服务器宕机，东西只是排队等待重新联机处理。
在查询端，理解索引如何工作以及数据如何存储是很重要的。有不同类型的索引，例如哈希表可以为您提供恒定的访问时间，但您不能使用哈希表执行范围查询。最简单的是，如果您有简单的分散数据对象，可以通过标识符查询，这些标识符可以存储在索引中。如果你的数据更复杂，你需要做大量的连接或聚合，那么你可以查看预先计算的值存储在Redis或memcache中。