>  기사  >  백엔드 개발  >  Go에서 사용자 일일 한도를 구현하는 방법

Go에서 사용자 일일 한도를 구현하는 방법

藏色散人
藏色散人앞으로
2022-01-10 15:55:173201검색

이 글은 golang튜토리얼 칼럼에서 Go에서 사용자의 일일 한도를 구현하는 방법을 소개하기 위해 작성한 글입니다. 필요한 친구들에게 도움이 되길 바랍니다!

Go에서 사용자 일일 한도 구현(예: 하루에 3번만 혜택을 받을 수 있음)

버그 관리 시스템을 작성하고 이 PeriodLimit을 사용하면 각 테스터가 하루에 하나의 버그만 제출하도록 제한할 수 있습니다. 일이 훨씬 쉬워졌나요? :PPeriodLimit 你就可以限制每个测试人员每天只能给你提一个 bug。工作是不是就轻松很多了?:P

如今微服务架构大行其道本质原因是因为要降低系统的整体复杂度,将系统风险均摊到子系统从而最大化保证系统的稳定性,通过领域划分拆成不同的子系统后各个子系统能独立的开发、测试、发布,研发节奏和效率能明显提高。

但同时也带来了问题,比如:调用链路过长,部署架构复杂度提升,各种中间件需要支持分布式场景。为了确保微服务的正常运行,服务治理就不可或缺了,通常包括:限流,降级,熔断。

其中限流指的是针对接口调用频率进行限制,以免超出承载上限拖垮系统。比如:

  • 电商秒杀场景

  • API 针对不同商户限流

常用的限流算法有:

  • 固定时间窗口限流
  • 滑动时间窗口限流
  • 漏桶限流
  • 令牌桶限流

本文主要讲解固定时间窗口限流算法。

工作原理

从某个时间点开始每次请求过来请求数+1,同时判断当前时间窗口内请求数是否超过限制,超过限制则拒绝该请求,然后下个时间窗口开始时计数器清零等待请求。

Go에서 사용자 일일 한도를 구현하는 방법

优缺点

优点

实现简单高效,特别适合用来限制比如一个用户一天只能发10篇文章、只能发送5次短信验证码、只能尝试登录5次等场景,实际业务中此类场景非常多见。

缺点

固定时间窗口限流的缺点在于无法处理临界区请求突发场景。

假设每 1s 限流 100 次请求,用户在中间 500ms 时开始 1s 内发起 200 次请求,此时 200 次请求是可以全部通过的。这就和我们预期 1s 限流 100 次不合了,根源在于限流的细粒度太粗。

Go에서 사용자 일일 한도를 구현하는 방법

go-zero 代码实现

core/limit/periodlimit.go

go-zero 中使用 redis 过期时间来模拟固定时间窗口。

redis lua 脚本:

-- KYES[1]:限流器key-- ARGV[1]:qos,单位时间内最多请求次数-- ARGV[2]:单位限流窗口时间-- 请求最大次数,等于p.quotalocal limit = tonumber(ARGV[1])-- 窗口即一个单位限流周期,这里用过期模拟窗口效果,等于p.permitlocal window = tonumber(ARGV[2])-- 请求次数+1,获取请求总数local current = redis.call("INCRBY",KYES[1],1)-- 如果是第一次请求,则设置过期时间并返回 成功if current == 1 then
  redis.call("expire",KYES[1],window)
  return 1-- 如果当前请求数量小于limit则返回 成功elseif current limit则返回 失败else
  return 0end

固定时间窗口限流器定义

type (
  // PeriodOption defines the method to customize a PeriodLimit.
  // go中常见的option参数模式
  // 如果参数非常多,推荐使用此模式来设置参数
  PeriodOption func(l *PeriodLimit)

  // A PeriodLimit is used to limit requests during a period of time.
  // 固定时间窗口限流器
  PeriodLimit struct {
    // 窗口大小,单位s
    period     int
    // 请求上限
    quota      int
    // 存储
    limitStore *redis.Redis
    // key前缀
    keyPrefix  string
    // 线性限流,开启此选项后可以实现周期性的限流
    // 比如quota=5时,quota实际值可能会是5.4.3.2.1呈现出周期性变化
    align      bool
  }
)

注意一下 align 参数,align=true 时请求上限将会呈现周期性的变化。
比如quota=5时实际quota可能是5.4.3.2.1呈现出周期性变化

限流逻辑

其实限流逻辑在上面的 lua 脚本实现了,需要注意的是返回值

  • 0:表示错误,比如可能是 redis 故障、过载
  • 1:允许
  • 2:允许但是当前窗口内已到达上限,如果是跑批业务的话此时可以休眠 sleep 一下等待下个窗口(作者考虑的非常细致)
  • 3:拒绝
// Take requests a permit, it returns the permit state.
// 执行限流
// 注意一下返回值:
// 0:表示错误,比如可能是redis故障、过载
// 1:允许
// 2:允许但是当前窗口内已到达上限
// 3:拒绝
func (h *PeriodLimit) Take(key string) (int, error) {
  // 执行lua脚本
  resp, err := h.limitStore.Eval(periodScript, []string{h.keyPrefix + key}, []string{
    strconv.Itoa(h.quota),
    strconv.Itoa(h.calcExpireSeconds()),
  })

  if err != nil {
    return Unknown, err
  }

  code, ok := resp.(int64)
  if !ok {
    return Unknown, ErrUnknownCode
  }

  switch code {
  case internalOverQuota:
    return OverQuota, nil
  case internalAllowed:
    return Allowed, nil
  case internalHitQuota:
    return HitQuota, nil
  default:
    return Unknown, ErrUnknownCode
  }
}

这个固定窗口限流可能用来限制比如一个用户一天只能发送5次验证码短信,此时我们就需要跟中国时区对应(GMT+8),并且其实限流时间应该从零点开始,此时我们需要额外对齐(设置 align 为 true)。

// 计算过期时间也就是窗口时间大小
// 如果align==true
// 线性限流,开启此选项后可以实现周期性的限流
// 比如quota=5时,quota实际值可能会是5.4.3.2.1呈现出周期性变化
func (h *PeriodLimit) calcExpireSeconds() int {
  if h.align {
    now := time.Now()
    _, offset := now.Zone()
    unix := now.Unix() + int64(offset)
    return h.period - int(unix%int64(h.period))
  }

  return h.period
}

项目地址

github.com/zeromicro/go-zero

欢迎使用 go-zero요즘 마이크로서비스 아키텍처가 인기를 끄는 근본적인 이유는 시스템의 전반적인 복잡성을 줄이고, 시스템 위험을 하위 시스템에 균등하게 분산하여 시스템의 안정성을 극대화하고, 도메인을 통해 여러 하위 시스템으로 분할하는 것입니다. Division 결국 각 하위 시스템은 독립적으로 개발, 테스트 및 출시될 수 있으며 R&D 리듬과 효율성이 크게 향상될 수 있습니다.

그러나 호출 링크가 너무 길고 배포 아키텍처의 복잡성이 증가하며 다양한 미들웨어가 분산 시나리오를 지원해야 하는 등의 문제도 발생합니다. 마이크로서비스의 정상적인 작동을 보장하려면 일반적으로 전류 제한, 다운그레이드 및 회로 차단기를 포함하는 서비스 거버넌스가 필수적입니다. 🎜🎜전류 제한이란 부하 제한을 초과하여 시스템이 다운되는 것을 방지하기 위해 인터페이스 호출 빈도를 제한하는 것을 의미합니다. 예: 🎜
  • 🎜전자상거래 반짝 세일 시나리오🎜
  • 🎜다양한 판매자에 대한 API 현재 제한🎜
  • 🎜일반적으로 사용되는 전류 제한 알고리즘은 다음과 같습니다: 🎜
    • 고정 시간 창 전류 제한
    • 슬라이딩 시간 창 전류 제한
    • 누설 버킷 전류 제한
    • 토큰 버킷 전류 제한
    🎜이 문서에서는 주로 고정 시간 창 전류 제한 알고리즘에 대해 설명합니다. 🎜

    작동 원리

    🎜특정 시점부터 요청당 요청 수가 +1이 되며, 동시에 현재 시간 창 내에서 요청 수가 한도를 초과하는지 여부가 결정됩니다. 한도를 초과하면 요청이 거부됩니다. 그런 다음 카운터는 초기화되어 요청을 기다리게 됩니다. 다음 시간 창. 🎜🎜Go에서 사용자 일일 한도를 구현하는 방법 🎜

    장점과 단점

    🎜🎜🎜장점🎜🎜🎜구현은 간단하고 효율적이며 특히 제한에 적합합니다. 예를 들어, 하루에 한 명의 사용자 대 한 명의 사용자만 글을 10개 게시할 수 있고, SMS 인증 코드를 5번만 보낼 수 있으며, 로그인을 5번만 시도할 수 있습니다. 이러한 시나리오는 실제 비즈니스에서 매우 일반적입니다. 🎜🎜🎜🎜단점🎜🎜🎜고정 시간 창 전류 제한의 단점은 갑작스러운 중요 섹션 요청 시나리오를 처리할 수 없다는 것입니다. 🎜🎜현재 제한은 1초마다 100개의 요청이고 사용자가 중간 500ms부터 1초 내에 200개의 요청을 시작한다고 가정하면 이때 200개의 요청을 모두 통과할 수 있습니다. 이는 전류를 초당 100회로 제한하려는 우리의 기대와 일치하지 않습니다. 근본 원인은 전류 제한의 세분화가 너무 거칠기 때문입니다. 🎜🎜Go에서 사용자 일일 한도를 구현하는 방법🎜

    제로 코드 구현

    🎜🎜core/limit/ periodlimit.go🎜🎜 Go-zero는 Redis 만료 시간을 사용하여 고정된 시간 창을 시뮬레이션합니다. 🎜🎜🎜redis lua 스크립트: 🎜rrreee🎜🎜고정 시간 창 현재 제한기 정의🎜rrreee🎜정렬 매개변수에 주의하세요. align=true이면 요청 상한이 주기적으로 변경됩니다.
    예를 들어 quota=5인 경우 실제 할당량은 5.4.3.2.1이 될 수 있으며, 이는 주기적 변경을 표시합니다🎜🎜🎜현재 제한 논리🎜🎜실제로 현재 제한 논리는 위에서 구현됩니다. lua 스크립트, 참고하세요. 반환 값은 🎜
    • 0: Redis 실패 또는 과부하와 같은 오류를 나타냅니다.
    • 1: 허용
    • 2: 허용되지만 현재 창 내에서 상한에 도달했습니다. 일괄 사업을 운영하는 경우에는 이때 잠을 자고 다음 창을 기다리면 됩니다(저자가 매우 신중하게 고려했습니다)
    • 3: 거부
    rrreee🎜이 고정 창 현재 제한은 예를 들어 사용자가 하루에 5번만 인증 코드 문자 메시지를 보낼 수 있도록 제한하는 데 사용될 수 있습니다. 이때 중국 시간대에 해당해야 합니다. (GMT+8)이며 실제로 현재 제한 시간은 0부터 시작해야 합니다. 이때 추가 정렬이 필요합니다(align을 true로 설정). 🎜rrreee

    프로젝트 주소

    🎜github.com/zeromicro/go-zero🎜🎜go-zero 사용을 환영하고 🎜star🎜 지원해 주세요! 🎜

위 내용은 Go에서 사용자 일일 한도를 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
이 기사는 learnku.com에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제