今天就跟大家聊聊有关Go语言中怎么实现每分钟处理100万个请求，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
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万个请求有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
