本文介绍: 重点讲清楚令牌桶原理,在支付系统的应用场景,以及使用reids实现的核心代码。

这是《百图解码支付系统设计与实现》专栏系列文章中的第(17)篇,也是流量控制系列的第(4)篇。点击上方关注,深入了解支付系统的方方面面。

本篇重点讲清楚令牌桶原理,在支付系统的应用场景,以及使用reids实现的核心代码。

在流量控制系列文章中的前三篇,分别介绍了固定时间窗口算法、滑动时间窗口算法、漏桶原理、应用场景和redis核心代码。

我们做个简单回顾:

固定窗口:算法简单,对突然流量响应不够灵活。超过流量的会直接拒绝,通常用于限流。

  1. 令牌桶:令牌桶本质上是一个存放令牌的容器,其中令牌代表着可以执行某个操作的许可或权利。这个桶以固定的速率往其中放入令牌。
  2. 令牌生成速率:令牌桶算法规定了每秒往令牌桶中添加令牌的速率,通常以令牌/秒(Tokens Per Second,TPS)或类似的单位来表示。
  3. 令牌消耗:当一个请求到来时,它需要获取一个令牌才能继续执行。如果桶中有可用令牌,请求将获得一个令牌,并被允许执行。否则,请求将被阻塞或拒绝。
  4. 限制速率:通过控制令牌生成速率,令牌桶算法限制了请求的速率,确保不会发生过于频繁的请求,从而避免了系统的过载。
  5. 处理突发流量:令牌桶允许短时间内处理突发流量,因为它可以在桶中积累多个令牌,允许一次性处理多个请求,但仍然受到桶的容量限制。
  6. 令牌桶容量:令牌桶还具有一个容量,表示桶中最多可以存放多少个令牌。如果桶已满,新的令牌将被丢弃。
  • zremrangeByScore 用于移除窗口之外的旧请求。
  • zcard 获取当前窗口内的请求数量。
  • zadd 将新请求添加到集合中。
  1. 上述代码只是示例,真实的代码还有很多异常处理,比如队列数据丢失,需要重新处理。
  2. 暂时只能用于退款,因为退款的时效要求不高。另外,单机只需要开一个线程就行,因为服务器是分布式部署,多个服务器合并起来仍然是多个线程在并发处理。对退款是足够的。
  1. 合理设置参数:令牌生成的速率和桶的容量需要根据实际情况调整,以平衡响应性和限制性。
  2. 系统时间同步:在分布式环境中,确保所有节点的系统时间同步非常重要,以避免时间偏差导致的算法执行错误。
  3. 资源预留:在高并发场景下,令牌桶算法可能导致大量请求被暂时阻塞,需要确保系统有足够的资源来处理这些积压的请求。
  4. 监控与调整:持续监控令牌桶的性能,并根据系统负载情况进行动态调整。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注