ruby-on-rails - 实用排队论

Question

我想学习足够简单/实用的排队理论来模拟标准 Web 应用程序堆栈的行为:具有多个应用程序服务器后端的负载均衡器。

鉴于从 NewRelic 之类的工具中提取的简单流量模式显示了应用程序给定部分的流量百分比和该应用程序部分的平均响应时间，我认为我应该能够使用负载均衡器配置对不同的排队行为进行建模，数量应用服务器和排队模型。

任何人都可以帮助我指出排队理论介绍/基础知识我需要用数学方式表示这个系统吗？我很尴尬地说我在本科时就知道如何做到这一点，但后来忘记了所有的基础知识。

我的目标是对不同的负载均衡器和应用服务器队列模型进行建模并测量结果。

例如，很明显，N-mongrel Ruby on Rails 应用程序堆栈在每个 Mongrel 上有一个队列时，比 Unicorn/Passenger 系统为每组应用程序工作人员设置一个队列时，延迟/等待时间更短。

Answer 1

我不能指点你在理论上，但有一些常用的基本方法:

盲(线性或加权)循环 - 请求在 n 个服务器之间循环，可能根据某种权重。每个后端维护一个请求队列。运行缓慢的请求会备份该工作人员的请求队列。停止返回结果的工作人员最终会从平衡器池中删除，当前排队的所有请求都将被删除。这对于 haproxy/nginx 平衡设置很常见。

全局池——一个主队列维护一个请求列表，当他们有空接受新请求时，工作人员会报告。 master 将队列的前端交给可用的 worker。如果 worker 宕机，只有当前正在处理的请求会丢失。在理想情况下会导致性能略有下降(所有工作人员都启动并快速返回请求)，因为队列主控和后端之间的通信是实际移交工作的先决条件，但具有自然避免缓慢、死亡或停滞的工作人员的好处。乘客默认使用此平衡算法，haproxy 使用其变体及其“leastconn”平衡算法。

散列平衡 - 请求的某些组件被散列，结果散列决定使用哪个后端。 memcached 使用这种策略进行分片设置。不利的一面是，如果您的集群配置发生更改，则之前的所有散列都将无效，并且可能会映射到与以前不同的后端。特别是在 memcached 的情况下，这可能导致您的大部分或全部缓存数据失效(由于此类问题，reddit 最近遭受了 some massive performance problems)。

一般来说，对于 Web 应用程序，我倾向于使用全局池化方法，因为当您有缓慢或死掉的工作人员时，它可以保持最流畅的用户体验。