重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
今天就跟大家聊聊有关Go语言中怎么实现每分钟处理100万个请求,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
创新互联公司是专业的武义网站建设公司,武义接单;提供成都网站设计、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行武义网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
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万个请求有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。