일반적으로 사용되는 4가지 전류 제한 알고리즘을 마스터하면 반드시 인터뷰에 합격할 수 있습니다.

전자상거래 프로모션 등 동시 접속률이 높은 상황에서는 트래픽이 계속해서 쏟아져 나오고, 서비스 간 상호 통화 빈도가 급격하게 늘어나 시스템 부하가 너무 높아지게 됩니다. 이때 시스템의 안정성이 너무 높아집니다. 시스템이 의존하는 서비스 시스템에 미치는 영향은 매우 크고, 네트워크 연결 중단, 서비스 다운타임 등 산사태를 일으키는 불확실한 요인이 많이 있습니다. 일반적으로 마이크로서비스 내결함성 구성 요소는 마이크로서비스 시스템을 효과적으로 보호할 수 있는 전류 제한, 격리, 성능 저하, 회로 차단기 및 기타 수단을 제공합니다. 이 기사에서는 주로 전류 제한에 대해 설명합니다.

전류 제한은 작동 주파수가 정의된 제한을 초과하지 않도록 최대 유량을 제한하는 것을 의미합니다. 시스템이 제공할 수 있는 최대 동시성은 제한되어 있고, 동시에 요청이 너무 많아서 반짝 세일, 대규모 프로모션 등 조절이 필요합니다. 즉각적으로 많은 요청이 쇄도하면 서버가 이를 처리할 수 없습니다. 그래서 스로틀링을 해야 합니다. 속도 제한은 특정 기간 동안 API에 도달할 수 있는 요청 수를 제한하여 우발적이거나 악의적인 남용으로부터 서비스를 보호합니다. 속도 제한이 없으면 모든 사용자가 서버에 요청을 쏟아부어 다른 사용자가 굶어 죽는 상황을 초래할 수 있습니다.

속도 제한은 왜 있나요?

• Prevent Resource Starvation: 속도 제한의 가장 일반적인 이유는 리소스 부족을 방지하여 API 기반 서비스의 가용성을 높이는 것입니다. 속도 제한을 적용하면 로드 기반 서비스 거부(DoS) 공격을 방지할 수 있습니다. 한 사용자가 수많은 요청으로 API를 공격하더라도 다른 사용자는 굶어 죽지 않습니다.
• 보안: 속도 제한은 로그인, 프로모션 코드 등과 같은 보안 중심 기능에 대한 무차별 대입 공격을 방지합니다. 이러한 기능에 대한 요청 수는 사용자 수준에서 제한되므로 이러한 시나리오에서는 무차별 대입 알고리즘이 작동하지 않습니다.
• 운영 비용 방지: 종량제 모델에서 리소스를 자동으로 확장하는 경우 속도 제한은 리소스 확장에 가상 상한선을 설정하여 운영 비용을 제어하는 ​​데 도움이 됩니다. 속도 제한이 없으면 리소스가 불균형적으로 확장되어 요금이 기하급수적으로 늘어날 수 있습니다.

속도 제한 정책 속도 제한은 다음 매개변수에 적용될 수 있습니다.

• Users: 특정 기간 동안 사용자에게 허용되는 요청 수를 제한합니다. 사용자 기반 속도 제한은 가장 일반적이고 직관적인 속도 제한 형식 중 하나입니다.
• Concurrency: 이는 특정 기간 동안 사용자가 허용할 수 있는 병렬 세션 수를 제한합니다. 병렬 연결 수를 제한하면 DDOS 공격을 완화하는 데에도 도움이 됩니다.
• Location/ID: 이는 위치 기반 또는 인구 통계 중심 캠페인을 실행하는 데 도움이 됩니다. 대상 인구 통계에서 나오지 않는 요청은 제한되어 대상 지역의 가용성을 높일 수 있습니다
• Servers: 서버 기반 속도 제한은 틈새 전략입니다. 이는 일반적으로 특정 서버가 대부분의 요청을 요구할 때 사용됩니다. 즉, 서버가 특정 기능과 강력하게 결합되어 있습니다

다음으로 4가지 일반적인 전류 제한 알고리즘

1을 소개하겠습니다. Leaky Bucket 알고리즘의 아이디어는 간단하고 직관적인 알고리즘으로 일정한 고정된 속도로 물방울이 흘러나오는 고정된 용량의 Leaky Bucket입니다. 양동이가 비어 있으면 물 한 방울도 흐를 필요가 없습니다. 물은 어떤 방식으로든 새는 물통으로 흘러 들어갈 수 있습니다. 유입되는 물방울이 물통의 용량을 초과하면 유입되는 물방울은 넘치게 되며(폐기됨), 새는 물통의 용량은 그대로 유지됩니다.

이 알고리즘의 장점은 급증하는 요청을 원활하게 하고 이를 일정한 속도로 처리한다는 것입니다. 또한 로드 밸런서에서 구현하기 쉽고 모든 사용자에게 메모리 효율적입니다. 요청 수에 관계없이 서버에 대한 일정하고 거의 균일한 트래픽을 유지합니다.

단점은 요청이 폭증하면 버킷이 가득 차서 새로운 요청이 부족해질 수 있다는 것입니다. 또한 요청이 지정된 시간 내에 완료된다는 보장도 없습니다.

장점:

교통이 원활합니다.

누수 버킷 알고리즘은 고정된 속도로 요청을 처리하기 때문에 트래픽을 효과적으로 원활하게 하고 형성하며 트래픽 버스트와 변동을 방지할 수 있습니다(메시지 대기열의 피크 감소 및 밸리 채우기 효과와 유사).

• 과부하를 방지하세요. 들어오는 요청이 버킷 용량을 초과하는 경우 시스템 과부하를 방지하기 위해 요청을 직접 삭제할 수 있습니다.
• 단점:
  • 폭발 트래픽을 처리할 수 없습니다: 누출 버킷의 내보내기 속도가 고정되어 있으므로 폭주 트래픽을 처리할 수 없습니다. 예를 들어 트래픽이 적은 경우에도 요청을 더 빠르게 처리할 수 없습니다.
  • 데이터 손실 가능성: 유입 트래픽이 너무 크고 버킷 용량을 초과하는 경우 일부 요청을 삭제해야 합니다. 이는 누락된 요청을 용인할 수 없는 일부 시나리오에서 문제가 될 수 있습니다.

  2. 토큰 버킷 알고리즘

  토큰 버킷 알고리즘: 한도가 2r/s라고 가정하면 토큰은 500밀리초의 고정 속도로 버킷에 추가됩니다. 버킷에는 최대 b개의 토큰을 저장할 수 있습니다. 버킷이 가득 차면 새로 추가된 토큰은 폐기되거나 거부됩니다. n바이트 크기의 패킷이 도착하면 n개의 토큰이 버킷에서 제거되고 패킷이 네트워크로 전송됩니다. 버킷에 n개 미만의 토큰이 있는 경우 토큰은 삭제되지 않으며 패킷 흐름이 제한됩니다(폐기되거나 대기하도록 버퍼링됨). 토큰 버킷 전류 제한 원리는 그림과 같습니다.

  
  

  

  현재 제한 서버의 토큰 버킷은 실제 서비스 성능 및 기간에 따라 토큰 생성 속도와 버킷 용량을 조정할 수 있습니다. 비율을 높여야 하는 경우 버킷에 넣는 토큰의 비율은 요청에 따라 늘릴 수 있습니다.

  토큰이 생성되는 비율은 일정하지만 토큰을 얻기 위해 요청하는 비율은 제한되지 않습니다. 즉, 순간적인 대규모 트래픽에 직면했을 때 알고리즘은 짧은 시간 내에 많은 수의 토큰을 얻을 수 있으며 토큰을 얻는 과정에서 많은 리소스를 소비하지 않습니다

  각 새로운 요청이 서버에 도착할 때 , 실행됩니다. 두 가지 작업:

  Get Tokens
  • : 이 사용자의 현재 토큰 수를 가져옵니다. 정의된 제한보다 크면 요청이 삭제됩니다.
  토큰 업데이트
  • : 획득한 토큰이 기간 d 제한보다 작으면 요청을 수락하고 토큰을 첨부합니다.
  알고리즘은 애플리케이션에 대해 사용자당 더 적은 양의 데이터를 저장하므로 메모리 효율적입니다. 여기서 문제는 분산 환경에서 경쟁 조건이 발생할 수 있다는 것입니다. 이는 서로 다른 두 애플리케이션 서버의 두 요청이 동시에 토큰을 가져오려고 할 때 발생합니다.

  장점:

  버스트 트래픽을 처리할 수 있습니다.
  • : 토큰 버킷 알고리즘은 버스트 트래픽을 처리할 수 있습니다. 버킷이 가득 차면 요청을 최대 속도로 처리할 수 있습니다. 이는 급증하는 트래픽을 처리해야 하는 애플리케이션에 유용합니다.
  평균 속도 제한
  • : 장기적으로 데이터 전송 속도는 미리 정의된 평균 속도(즉, 토큰이 생성되는 속도)로 제한됩니다.
  Flexibility
  • : Leaky 버킷 알고리즘에 비해 토큰 버킷 알고리즘은 더 큰 유연성을 제공합니다. 예를 들어, 토큰 생성 속도를 동적으로 조정할 수 있습니다. 단점:
  과부하를 일으킬 수 있음
  • : 토큰이 너무 빨리 생성되면 대량의 트래픽 버스트가 발생하여 네트워크나 서비스에 과부하가 걸릴 수 있습니다.
  저장 공간 필요
  • : 토큰 버킷은 토큰을 저장하기 위해 일정량의 저장 공간이 필요하므로 메모리 리소스가 낭비될 수 있습니다.
  구현이 약간 복잡합니다
  • : 카운터 알고리즘과 비교하여 토큰 버킷 알고리즘의 구현이 약간 더 복잡합니다. 3. 고정 시간 창 알고리즘
  을 사용하면 고정된 시간 창 내에 특정 수의 요청이 들어갈 수 있습니다. 수량을 초과하면 거부되거나 다음 기간 동안 대기하기 위해 대기열에 추가됩니다. 이 카운터 전류 제한은 시간 간격 내에서 제한하여 구현됩니다. 사용자가 이전 간격이 끝나기 전에 요청을 보내고(제한을 초과하지 않음) 현재 간격이 시작될 때에도 요청을 보내는 경우(또한 제한을 초과하지 않음) 이러한 요청은 해당 요청에 대해 정상입니다. 각각의 간격. 그러나 중요한 기간 동안 요청이 시스템 제한을 초과하면 시스템 과부하가 발생할 수 있습니다

  카운터 알고리즘의 시간 임계점 결함으로 인해 시간 임계점을 중심으로 매우 짧은 시간 내에 공격에 취약합니다. 예를 들어 특정 인터페이스를 분당 최대 100번까지 요청하도록 설정되어 있습니다. 예를 들어 12:00:00~12:00:59 시간에는 데이터 요청이 없는데 갑자기 동시 요청이 있는 경우입니다. 12:00:59-12:01:00 기간 동안 100개의 요청이 있고 다음 계산 주기에 들어가면 카운터가 지워지고 12:01:00-12:01:01 사이에 100개의 요청이 있습니다. 즉, 시간 임계점 부근에서 동시에 임계값의 2배에 달하는 요청이 발생하여 백그라운드 처리 요청의 과부하가 발생하여 시스템 운영 능력이 부족해지고 심지어 시스템이 충돌하는 경우도 발생할 수 있습니다.

  단점:

  • 현재 제한이 충분히 원활하지 않습니다. 예를 들어 현재 제한은 초당 3개이며 첫 번째 밀리초에 3개의 요청이 전송됩니다. 현재 제한에 도달하면 남은 기간 동안의 모든 요청이 거부되어 좋지 않은 경험이 발생합니다.
  • 창 테두리 문제를 처리할 수 없습니다. 특정 시간 창 내에서 흐름 제어가 수행되기 때문에 창 경계 효과가 발생할 수 있습니다. 즉, 시간 창의 경계에서 많은 수의 요청이 통과되도록 허용되어 버스트 트래픽이 발생할 수 있습니다.

  예: 현재 제한은 초당 3개이며, 첫 번째 초의 마지막 밀리초에 3개의 요청이 전송되고, 두 번째 초의 첫 번째 밀리초에 3개의 요청이 전송됩니다. 이 2밀리미터 내에서 6개의 요청이 처리되었지만 현재 제한이 트리거되지 않았습니다. 트래픽이 폭증하면 서버에 과부하가 걸릴 수 있습니다.

  4. 슬라이딩 윈도우 알고리즘

  슬라이딩 윈도우 알고리즘은 고정된 기간을 분할하여 시간에 따라 이동하는 방식으로, 시작 시점이 시간 목록의 두 번째 시점이 되고 종료 시점이 추가됩니다. 특정 시점을 지정하고 이를 지속적으로 반복하면 카운터의 임계점 문제를 교묘하게 피할 수 있습니다.

  슬라이딩 윈도우 알고리즘은 카운터 알고리즘의 시간 임계점 문제를 효과적으로 피할 수 있지만 여전히 시간 세그먼트 개념이 있습니다. 동시에 슬라이딩 윈도우 알고리즘의 계산 작업은 고정 시간 윈도우 알고리즘보다 시간이 더 많이 소요됩니다.

  

  단점: 여전히 전류 한도가 충분히 원활하지 않다는 문제가 있습니다. 예를 들어 현재 제한은 초당 3개이며 첫 번째 밀리초에 3개의 요청이 전송됩니다. 현재 제한에 도달하면 남은 창 시간 내의 모든 요청이 거부되어 결과적으로 성능이 저하됩니다.

  요약

  일반적으로 사용되는 4가지 전류 제한 알고리즘인 고정 창 알고리즘, 슬라이딩 창 알고리즘, 누출 버킷 알고리즘 및 토큰 버킷 알고리즘을 소개했습니다. 각 알고리즘마다 고유한 특성과 적용 가능한 시나리오가 있으므로 아래에서 간략하게 요약하고 비교해 보겠습니다.

  • 토큰 버킷 알고리즘은 트래픽을 원활하게 하고 버스트 트래픽을 처리할 수 있으며 버스트 트래픽을 처리해야 하는 시나리오에 적합합니다.
  • Leaky Bucket Algorithm의 장점은 트래픽 처리가 더 원활하지만 버스트 트래픽에 대처할 수 없으며 원활한 트래픽이 필요한 시나리오에 적합하다는 것입니다.
  • 고정 창 알고리즘 은 구현이 간단하지만 전류 제한이 충분히 매끄럽지 않고 창 경계 문제가 있어 전류 제한을 간단하게 구현해야 하는 시나리오에 적합합니다.
  • 슬라이딩 윈도우 알고리즘은 윈도우 경계 문제를 해결하지만 여전히 전류 제한의 부드러움이 부족하다는 문제가 남아 있어 평균 요청 속도를 제어해야 하는 시나리오에 적합합니다.

위 내용은 일반적으로 사용되는 4가지 전류 제한 알고리즘을 마스터하면 반드시 인터뷰에 합격할 수 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!