Grab熔断器设计：如何应对突发打车峰值

在东南亚，一旦下雨每每就不小。它成为一个重要的情绪因素，尤为是当你被困在外面的时候，你就会面临糟糕的一天。程序员

在 Grab 的早期，若是雨来的时间不对，好比上班早高峰时间，那么咱们这些工程师那一天也很差过。算法

在那个时候，Grab 叫车服务的需求增加速度远超咱们的技术系统扩展能力，咱们常常要加班到深夜，以确保系统可以处理不断增加的请求。当打车预订量忽然激增时，咱们的系统仍是难以承载。安全

此外，还有其余因素致使了需求激增，例如，当公共交通服务出现故障，或者当大型活动如国际音乐会结束，全部的游客须要同时乘车。网络

通过思考，咱们发现这些突发事件背后有两个方面的因素。架构

第一，这些事件都是局部事件。需求的增长来自于一个特定的地理位置，有时是一个很小的区域。这些局部事件有可能对咱们的系统形成很大的负荷，以致于影响到地理位置之外的其余用户的体验。app

其次，潜在的问题是，这些特定地理区域当时缺少车辆供应。分布式

在 Grab，咱们的目标一直都是在每一个人须要的时候和地点都能找到合适的司机，但上面这种状况，原本也是不可能达到的。咱们须要找到一种方法来确保这种局部的需求激增不会影响到咱们知足其余用户需求的能力。ide

使用 Spampede 熔断器

Spampede 熔断器的灵感来自于咱们以前博客上曾经提过的一个概念--熔断器。https://engineering.grab.com/designing-resilient-systems-part-1微服务

在软件中，就如电子产品中同样，熔断器的设计是为了保护系统在面对不利条件下的短路。spa

下面咱们来分析一下。

熔断器包括两个关键的概念：熔断和不利条件。

首先，熔断，在这里指的是对特定的订单量可以经过的最小处理量，经过这样作，减小系统的总体负荷。第二，不利条件，指的是在短期内，在一个小的地理区域内，存在对某项服务大量未完成的请求。基于这两个概念，咱们设计了如下流程。

首先，咱们须要以位置感知的方式跟踪未分配的请求。为了作到这一点，咱们使用 Geohash 整数算法对未分配请求的取值位置进行转换。

转换后，获得的值就是一个准确的位置。咱们能够经过下降精度，将这个位置转换为 "桶" 或区域。

这种方法毫不是最好的，固然也不彻底跟当地的地理位置相关，可是它的 CPU 效率很是高，并且不须要经过网络 API 调用外部资源。

如今咱们能够跟踪未分配的请求，咱们须要一种方法让跟踪有时间维度相关。毕竟，交通情况、司机位置和乘客需求是不断变化的。咱们原本能够实现像滑动窗口总和这样的精确的东西，可是这样作会带来不少的复杂性，并且 CPU 和内存成本也会大大增长。

经过使用 Unix 时间戳，咱们经过直接的公式将当前时间转换为 "桶" 的时间。

其中 bs 为时间桶的大小，单位为秒数。

经过位置和时间桶的计算，咱们能够用 Redis 来追踪未分配的预订。也可使用其余的数据存储软件，但 Redis 对咱们来讲很是熟悉，它也是通过实战检验的。

为了作到这一点，咱们首先经过结合服务类型、地理位置和时间桶来构建 Redis key。有了这个 key，咱们调用增长计数 INCR 命令，它将存储在该位置的值递增，并返回新的值。

若是返回的值是 1，这代表本地调用是这个时间桶的第一个值，而后咱们将进行第二次调用 EXPIRE。将在 Redis 项上设置一个存活时间（TTL），让数据进行自我清理。

你会注意到，咱们是盲目的调用增量，只在须要的时候再进行第二次 EXPIRE 调用。这种模式比起使用更传统的、load-check-store 的模式更有效率，也更节省资源。

下一步就是配置了。具体来讲，就是设置在熔断器开启以前，在特定的位置和时间桶中，能够存在多少个未分配的预订量。咱们再次使用 Redis。一样，使用 Redis 是由于对它至关熟悉。

最后要说明的是，咱们在预订处理开始前就执行了检查，强调一下，在调用任何其余服务以前，咱们就执行了检查代码。这个代码会将地点、时间和所请求的服务与当前配置的 Spampede 设置，以及以前未分配的预订量进行比较。若是已经达到了最大值，那么咱们当即中止处理。

这听起来可能有点刺耳 — 尚未尝试调用就当即拒绝？但 Spampede 过滤器的设计目的就是为了防止过分的、局部的需求影响到系统的全部用户。

做为一个程序员，读到这里，可能会以为很奇怪，有意把预订量降下来，这样会影响业务的发展。

说到底，咱们想要作的只是帮助人们到达他们想要去的地方。这个过程是一个系统安全机制：确保系统健康并可以达成送达乘客这一目标。

若是我不强调一下这是关键软件工程的启示，是观察者效应和 CAP 定理的基本目标的结合，那我就失职了。观察者效应是指为了观察一个系统带来的指令及监控等成本，会对系统自己的运行产生影响。

通常来讲，监测和限制的精度或一致性越高，消耗资源成本就越高。

在这种状况下，咱们有意选择了最节省资源的方案，用较低的精度来换取更多的吞吐量。

参考阅读：

本文由高可用架构翻译，技术原创及架构实践文章，欢迎经过公众号菜单「联系咱们」进行投稿。