共计 1855 个字符，预计需要花费 5 分钟才能阅读完成。
自动写代码机器人，免费开通
今天就跟大家聊聊有关 Go 语言中怎么实现每分钟处理 100 万个请求，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
Go 语言程序的单纯方法
最初我们采取了一个非常单纯的 POST 处理方式，仅仅试图将任务并行化处理放到一个简单的 goroutine：
对于中等负载来说，这可能对大多数人是有效的，但这很快证明在大型负载时，效果不太好。我们预期有很多的请求，但当我们部署第一个版本到产品中时，并没有看到这个数量级的请求。我们完全低估了流量。
上面的方法在几个方面都不好，没有办法控制我们正在大量生产的 Go 程序要产生多少个例程。由于我们每分钟收到 100 万个 POST 请求，理所当然的，这段代码很快就崩溃了。
再次尝试
我们需要寻找一个不同的方式。从一开始，我们就讨论如何保持请求处理程序的生命周期非常短，并在后台生成处理进程。当然，这是必须在 Ruby on Rails 领域要做的，否则这将限制所有可用的 web 处理器，无论你使用的是 puma, unicorn, passenger 中的哪一个（请不要参加 JRuby 讨论）。那么我们就需要利用通用的解决方案去做这个，例如 Resque, Sidekiq, SQS, 等等。清单还可以继续列下去，因为有很多方法可以做到这一点。
所以第二个版本是创建一个缓存通道，在这里我们可以对一些作业进行排队并上传到 S3，由于我们可以控制队列中的最大项目数，在内存中我们有足够多的 RAM 对任务进行排队，我们认为只在通道队列中缓存作业是可以的。
然后实际上的作业出列和处理，我们使用的是类似的函数：
说实话，我不知道我们在想什么。这一定是一个充满红牛的深夜。这种方法没有给我们带来任何好处，我们用缓冲队列来交换有缺陷的并发，也只是推迟了问题的产生时间而已。我们的同步处理器一次只上传一个有效负载到 S3, 而且由于传入请求的速率比单处理器上传到 S3 的能力大得多，所以缓冲通道很快就达到了极限，限制了请求处理程序来排队更多项目的能力。
我们只是简单地回避这个问题，最终导致系统的死亡。在我们部署了这个有缺陷的版本之后，我们的延迟率以不变的速率持续增长。
更好的解决方案
当使用 Go 语言通道时，我们决定利用通用模式以便创造一个 2 阶的通道系统，一个用于作业排队，另外一个控制多少作业者同时在 JobQueue 上操作。
这个想法是以某种可持续的速度并行上传到 S3，它既不会削弱机器性能，也不会从 S3 开始生成连接错误。所以我们选择了创建一个作业 / 作业者模式。对那些熟悉 java,C# 等语言的人来说，可以考虑采用 Go 语言实现通道方式而不是作业者线程池的方式。
我们修改了 Web 请求处理程序，创建一个带负载的 jobstruct 实例，发送到 JobQueue 通道，便于作业者去拾取。
在网站服务器初始化过程中，我们创建一个 Dispatcher，调用 Run() 去创建一个作业者池，开始侦听出现在 JobQueue 的作业。
dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()
下面是用于 dispatcher 执行的代码：
注意，我们会提供被实例化和被添加到作业者池的最大的作业者量。因为我们这个带有 dockerized Go 环境的项目使用了亚马逊 Elasticbeanstalk，我们总是设法遵循 12 要素方法论来配置生产中的系统，从环境变量中读取这些数值。这样就可以控制有多少作业者和作业队列的最大值，因此，我们可以快速地调整这些值，而不需要重新部署集群。
var (
MaxWorker = os.Getenv(“MAX_WORKERS”)
MaxQueue = os.Getenv(“MAX_QUEUE”)
)
在部署完它之后，我们立刻发现所有的延迟率都降到了无关紧要的数字，系统处理请求的能力急剧上升。
弹性负载均衡完全预热几分钟后，我们看到 ElasticBeanstalk 应用服务每分钟逼近 100 万个请求。通常在早晨的几个小时里，流量高峰会超过每分钟 100 万个请求。
一旦我们部署了新的代码，服务器的数量从 100 台减少到大约 20 台。
在恰当地配置了集群和自动缩放设置以后，我们能够把它降低到仅有 4x EC2 c4。如果 CPU 连续 5 分钟超过 90%，大型实例和弹性自动缩放设置就生成一个新实例。
看完上述内容，你们对 Go 语言中怎么实现每分钟处理 100 万个请求有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。
向 AI 问一下细节
