大多数情况下，我们不须要他们同时实现两个开闭控制系统，但开闭在实际应用中是两个非常错综复杂、有很多技术细节的控制系统保护手段，尤其是在高网络流量时，了解你所采用的开闭控制系统的开闭演算法，将能较好地帮助你充分运用该开闭控制系统达到他们的商业需求和目的，并避免再次出现一些采用开闭控制系统可能带来的大小不一的难题。
副本桶演算法
副本桶（token bucket）演算法，指的是设计两个罐子（即“桶”），由某一模块稳步运行往该罐子中加进副本（token），副本能是简单的数字、字符串或组合，也能实际上是两个算数，接着每个允诺步入控制系统时，须要从桶中申领两个副本，所有允诺都必须有副本才能步入后端控制系统。当副本桶空时，拒绝允诺；当副本桶满时，无须往当中加进捷伊令牌。 副本桶演算法的构架如图1所示：
副本桶演算法的同时实现方法论如下：
首先会有两个表述的时间询问处的出访单次共振频率，比如每天1000人，每秒5个允诺之类，开闭控制系统一般最轻发射率是秒，再小就会即使同时实现和性能的原因而变得不准确或不稳定，假定是T秒内容许N个允诺，那么副本桶演算法则会使副本加进模块每T秒往副本桶中加进N个副本。
其次，副本桶须要有两个最轻值M，当副本加进模块检测到副本桶中已经有M个副本时，余下的副本会被弃置。反映到开闭控制系统中，能指出是现阶段控制系统容许的脉动最轻网络流量，但并非稳步最轻网络流量。比如副本桶中的副本最轻数量是100个，每秒钟朝著当中加进10个新副本，当副本满的这时候，突然再次出现100 TPS的网络流量，这这时候是能忍受的，但是倘若连续半分钟的100 TPS网络流量就不行，即使副本加进速率是一秒钟10个，加进速率太慢采用速率。
因此，但凡采用副本桶演算法的开闭控制系统，我们单厢注意到它在配置时明确要求两个参数：
平均共振频率（rate或average）高峰期共振频率（burst或peak）通过笔者的介绍，听众应该意识到，副本桶演算法的高峰期共振频率是有专指的，并并非指现阶段开闭控制系统容许的最低网络流量。即使这一描述可能会Brisach指出如果低于该共振频率的网络流量都能，但事实上并非这样，即使如果高于加进速率的网络流量稳步一段时间单厢再次出现难题。
换言之，副本桶演算法的开闭控制系统不容易计算出它全力支持的最低网络流量，即使它能动态全力支持的最低网络流量依赖于那整个季节内的网络流量变化情况即副本增量，而并非实际上依赖于两个脉动的副本量。
最后，布季谢模块允诺副本的这时候，副本桶会乱数挑选出两个副本递送出去，接着将该副本从桶中去除。注意，此时副本桶无须做别的操作，副本桶永远不会主动明确要求副本加进模块补充捷伊副本。
副本桶演算法有两个同一思想、方向相反的变种，被称为漏桶（leaky bucket）演算法，它是副本桶的一种改进，在商业应用中非常广泛。
漏桶演算法的基本思想，是将允诺看作水流，用两个底下有洞的桶盛装，底下的洞漏出水的速率是恒定的，所有允诺步入控制系统的这时候单厢先步入这个桶，并慢慢由桶流出交给后台服务。桶有两个固定大小，当水网络流量超过这个大小的这时候，多余的允诺单厢被弃置。
漏桶演算法的构架总的来看：
漏桶算法的同时实现方法论如下：
首先会有两个罐子存放允诺，该罐子有两个固定大小M，所有允诺单厢被先存放到该罐子中。该罐子会有两个转发方法论，该转发以每T秒N个允诺的速率循环发生。当罐子中允诺数已经达到M个时，拒绝所有捷伊允诺。因此同样地，漏桶演算法的配置也须要两个值：平均值（rate）和峰值（burst）。只是平均值这这时候是用来表示漏出的允诺数量，峰值则是表示桶中能存放的允诺数量。
注意：漏桶演算法和缓冲的开闭思想不是一回事！
同样是将允诺放在两个罐子中，漏桶演算法和缓冲并非两个用途，切不可搞混，它们的区别如下：
漏桶演算法中，存在桶中的允诺会以恒定的速率被漏给后端业务服务器，而缓冲思想中，放在缓冲区域的允诺只有等到后端服务器空闲下来了，才会被发出去。漏桶演算法中，存在桶中的允诺是原本就应该被控制系统处理的，是控制系统对外界宣称的预期，不应该被丢失，而缓冲思想中放在缓冲区域的允诺实际上是对意外状况的尽量优化，并没有任何强制明确要求这些允诺能被处理。漏桶演算法和副本桶演算法在思想上非常接近，而同时实现方向恰好相反，它们有如下的相同和不同之处：
副本桶演算法以固定速率补充能转发的允诺数量（副本），而漏桶演算法以固定速率转发允诺；副本桶演算法限制数量的是预算数，漏桶演算法限制数量的是实际允诺数；副本桶演算法在有爆发式增长的网络流量时能一定程度上接受，漏桶演算法也是，但当网络流量爆发时，副本桶演算法会使业务服务器直接承担这种网络流量，而漏桶演算法的业务服务器感受到的是一样的速率变化。因此，通过以上比较，我们会发现漏桶演算法略优于副本桶演算法，即使漏桶演算法对网络流量控制更平滑，而副本桶演算法在设置的数值范围内，会将网络流量波动忠实地转嫁到业务服务器头上。
漏桶演算法在Nginx和分布式的开闭控制系统比如Redis的开闭功能中都有广泛应用，是目前业界最流行的演算法之一。
时间询问处演算法
时间询问处演算法是比较简单、基础的开闭演算法，由于它比较粗略，不适合大型、网络流量波动大或者有更精细的网络流量控制需求的网站。
时间询问处演算法根据确定时间询问处的方式，能分为两种：
固定时间询问处演算法滑动时间询问处演算法固定时间询问处演算法最简单，相信如果让初次接触开闭理念的听众去快速设计同时实现两个开闭控制系统的话，也能很快想到这种演算法。这种演算法即固定两个季节内限定两个允诺共振频率，没有达到则让允诺通过，达到数量共振频率了就拒绝允诺。步骤如下：
先确定两个起始时间点，一般就是控制系统启动的时间。从起始时间点开始，根据我们的需求，设置两个最轻值M，开始接受允诺并从0开始为允诺算数。在季节T内，允诺算数超过M时，拒绝所有剩下的允诺。超过季节T后，重置算数。固定时间询问处演算法的思路固然简单，但是它的方法论是有难题的，它不适合网络流量波动大和有精细控制网络流量需求的服务。让我们看以下例子：
假定我们的季节T是1秒，允诺最轻值是10，在第一秒钟内，允诺数量分布是第500毫秒时有1个允诺，第800毫秒时有9个允诺，如图3所示：
这是对于第一秒钟而言，这个允诺分布是合理的。
此时第二秒的第200毫秒（即半分钟中的第1200毫秒）内，又来了10个允诺，如图4所示：
单独看第二秒依然是合理的，但是两个季节连在一起的这时候，就再次出现了难题，如图5所示：
从500毫秒到1200毫秒，短短700毫秒的时间内后端服务器就接收了20个允诺，这显然违背了一开始我们希望1秒最多10个的初衷。这种远远大于预期网络流量的网络流量加到后端服务器头上，是会造成不可预料的后果的。因此，人们改进了固定窗口的演算法，将其改为检查任何两个季节都不超过允诺数量共振频率的时间询问处演算法：滑动时间询问处演算法。
滑动时间询问处演算法明确要求当允诺步入控制系统时，回溯过去的季节T，找到当中的允诺数量，接着决定是否接受现阶段允诺，因此，滑动时间询问处演算法须要记录季节T内允诺到达的时间点，方法论如图6所示：
解释如下：
1、确定两个起始时间点，一般就是控制系统启动的时间，并记录该点为时间询问处的开始点。接着创建两个空的列表作为时间询问处内允诺步入的时间戳记录。
2、当允诺到来时，采用现阶段时间戳比较它是否在时间询问处起始点加上T季节（从开始点到开始点+T就是时间询问处）内。
如果在，则查看现阶段时间询问处内记录的所有允诺的数量：
如果超过，则拒绝允诺。如果没有，则将该允诺加入到时间戳记录中，并将允诺交给后端业务服务器。如果不在，则查看时间戳记录，将时间戳最久远的记录删除，接着将时间询问处的开始点更新为第二久远的记录时间，接着回到步骤2，再次检查时间戳是否在时间询问处内。滑动时间询问处尽管有所改进，但依然不能较好应对某一季节内突发大量允诺，而副本桶和漏桶演算法就由于容许指定平均允诺率和最轻脉动允诺率，它比时间询问处演算法控制更精确。
时间询问处演算法能通过多时间询问处来改进。比如，能设置两个1秒10 TPS的时间询问处开闭和两个500毫秒5 TPS的时间询问处开闭，二者同时运行，如此就能保证更精确的开闭控制。
队列法
队列法与漏桶演算法很类似，都是将允诺放入到两个区域，接着业务服务器从中提取允诺，但是队列法采用的是完全独立的外部控制系统，而并非依附于开闭控制系统。队列法的构架如图7所示：
与漏桶演算法相比，队列法的优势如下：
由业务方法论层决定允诺收取的速率。开闭控制系统即队列不须要再增加服务去消费这些允诺。这一手段将业务服务器完全隐藏在了客户端后面，由队列去承担所有网络流量，也能更好地保护自身不受到恶意网络流量的攻击。队列能采用更健壮、更成熟的服务，这些服务比开闭控制系统复杂，但能够忍受大得多的网络流量。比如，业务服务器采用的是像阿里云或者AWS这样的消息队列的话，业务服务器就不用担心扩容的难题了，如果允诺对动态性的明确要求不高。业务服务器由于采用了云服务，队列一端的扩容不用担心，而由于消息是自由决定拉取频率和处理速率，自身的扩容压力也就不那么大了。但队列法最轻的缺陷，就是服务器不能直接与客户端沟通，因此只适用于客户端令业务服务器执行任务且不明确要求响应的用例，所有客户端须要有实质响应的服务都不能采用。比如，业务服务器提供的服务是消息发送服务，那么这种模式就能的，但如果客户端是允诺某些用户信息，那这种方式就完全不可行了。
本文摘录自《深入浅出大型网站构架设计》
