功能请求: 为突发流量添加内置的连接创建速率限制器,具有空闲重试功能

特性请求: 添加内置的连接创建速率限制器, 并具有闲置的修复功能 。

□ 背景和问题 目前,当交通中断,所有闲置的连接被耗尽时,只要 " Totalcons < PoolSize " ,连接池允许所有待处理的请求同时启动TCP拨号。 这造成了连通性创建风暴:

• 数以百计的出轨者在同一瞬间拨打Redis,造成TCP在客户端和服务器端的握手高峰.
• 在连接创建成本(如:每拨~10ms)远高于每个请求执行成本(如:~1ms)的情景中,创建大量连接效率远低于短暂等待和重用已存在的连接.
• 游泳池几乎立即填充 " PoolSize " ,即使交通高峰时间很短,之后大多数连接设施闲置而最终失效,从而产生定期的破坏-重建循环。

□为什么一个定制的迪亚勒是不够的 社区的共同工作是用比率 ' 包扎拨号 ' 。 " 限制 " ,但这一办法有重大限制:

一旦一个请求通过闲置检查并进入"新接通"分支,即使等待拨号符号,它也永远不会回去检查新回的闲置连接. 这意味着:

1. 即使另一个请求在一毫秒后返回与闲置池的连接,等待请求仍将形成全新的连接,浪费了再利用的机会.
2. 速率限制器只会延缓连接的创建,它不能将请求重回闲置的队列,而闲置队列是短命请求更有效率的路径.

对于重复使用比创造更便宜的工作量来说,这是次于最佳的。

□ 建议的解决办法 在连接池中添加一个内建连接创建速率限制器,其行为如下:

1. 增加一个新的选项,例如 " DialRateLimit " / " DialRateBurst " ,以控制每秒创建的新连接的最大数量。
2. 当闲置的连接被耗尽而池子通常会形成新的连接时,首先从限速器中获取一个令牌.
3. ** 如果一个符号不能立即取出,而不是在拨号道上被阻断,则重新排出等待闲置连接的请求** (“Totalcons == poupSize”时使用的`Wait ForCon'道)。
4. 当一个连接被退回到闲置池时,照常唤起等待请求;如果等待请求能够取用闲置的连接,则无需拨打.
5. 只有当请求等待时间超过某个阈值(或闲置的连接仍然无法使用)时,才着手建立新的连接。

简言之:当拨号被节制时,宁可等待再利用,也不愿等待创建。

□ 预期效益

• 在交通中断期间平滑断开连接,消除拨号风暴。
• 大大地提高短期需求工作量的总体效率,因为重复使用比创造要便宜得多。
• 减少因下列原因造成的不必要的连接churn . . . . . . .