Django REST framework 스 트림 제한 기능 사용

본문 시작
먼저 흐름 제한 이라는 개념 을 말 하고 이 개념 을 최초 로 접 한 것 은 전단 에 있다.실제 업무 장면 은 검색 상자 에 문 자 를 입력 하여 검색 할 때 모든 문자 가 백 엔 드 인 터 페 이 스 를 호출 하 는 것 이 아니 라 정지 후에 야 인 터 페 이 스 를 호출 하 는 것 입 니 다.이 기능 은 전단 요청 과 렌 더 링 의 압력 을 줄 이 고 백 엔 드 인터페이스 접근 의 압력 을 줄 일 필요 가 있다.전단 과 유사 한 기능 의 코드 는 다음 과 같 습 니 다.

//         
function throttle(fn, delay) {
    var timer;
    return function () {
        var _this = this;
        var args = arguments;
        if (timer) {
            return;
        }
        timer = setTimeout(function () {
            fn.apply(_this, args);
            timer = null;
        }, delay)
    }
}

그러나 백 엔 드 의 제한 흐름 은 목적 상 전단 과 유사 하지만 실현 상 다 를 수 있 으 니 DRF 의 제한 흐름 을 살 펴 보 자.
1.DRF 의 흐름 제한
프로젝트 설정

# demo/settings.py

REST_FRAMEWORK = {
    # ...
    'DEFAULT_THROTTLE_CLASSES': (
        'rest_framework.throttling.AnonRateThrottle',
        'rest_framework.throttling.UserRateThrottle',
         'rest_framework.throttling.ScopedRateThrottle',
    ),
    'DEFAULT_THROTTLE_RATES': {
        'anon': '10/day',
        'user': '2/day'
    },
}

# article/views.py

#   ViewSet   
class ArticleViewSet(viewsets.ModelViewSet, ExceptionMixin):
    """
              API  。
    """
    queryset = Article.objects.all()
    #          
    throttle_classes = (UserRateThrottle,)
    serializer_class = ArticleSerializer

#   view   
@throttle_classes([UserRateThrottle])

제 가 설정 한 사용 자 는 하루 에 두 번 만 요청 할 수 있 기 때문에 세 번 째 요청 후 429 Too Many Requests 의 이상 을 드 립 니 다.구체 적 인 이상 정 보 는 다음 사용 가능 시간 이 86398 초 후 입 니 다.
2.흐름 제한 진급 설정
상기 프레젠테이션 의 흐름 제한 설정 은 사용자 에 대한 흐름 제한 에 적 용 됩 니 다.예 를 들 어 제 가 사용 자 를 바 꾸 어 계속 방문 하 는 것 은 두 번 의 기회 입 니 다.

$ curl -H 'Accept: application/json; indent=4' -u root:root   http://127.0.0.1:8000/api/article/1/ 
{
    "id": 1,
    "creator": "admin",
    "tag": "   ",
    "title": "  ",
    "content": "            
  
      
            
     "
}

세 가지 제한 류 를 각각 소개 하 다.

Anon RateThrottle 은 모든 사용자 가 인터페이스 에 접근 하 는 제한 에 적용 된다

사용자 RateThrottle 은 인증 요청 이 끝 난 후 인터페이스 접근 에 대한 제한 에 적 용 됩 니 다Scoped RateThrottle 은 여러 인터페이스 에 대한 접근 제한 에 적 용 됩 니 다.
따라서 세 가지 서로 다른 유형 은 서로 다른 업무 장면 에 적용 되 고 구체 적 으로 서로 다른 업무 장면 에 따라 선택 하 며 이에 대응 하 는 scope 의 주파수 설정 을 통 해 기대 하 는 효 과 를 얻 을 수 있다.
3.흐름 제한 사고 분석
만약 당신 이 인 코딩 을 해서 이 수 요 를 실현 한다 면 어떻게 실현 해 야 합 니까?
사실 이 기능 은 어렵 지 않 습 니 다.핵심 적 인 매개 변 수 는 시간,횟수,사용 범위 입 니 다.다음은 함수 호출 횟수 에 대한 제한 을 보 여 드 리 겠 습 니 다.

from functools import wraps

TOTAL_RATE = 2

FUNC_SCOPE = ['test', 'test1']


def rate_count(func):
    func_num = {
        #            
        func.__name__: 0
    }

    @wraps(func)
    def wrapper():
        if func.__name__ in FUNC_SCOPE:
            if func_num[func.__name__] >= TOTAL_RATE:
                raise Exception(f"{func.__name__}          ")
            result = func()
            func_num[func.__name__] += 1
            print(f"    {func.__name__}      ： {func_num[func.__name__]}")
            return result
        else:
            #              
            return func()

    return wrapper


@rate_count
def test1():
    pass


@rate_count
def test2():
    print("test2")
    pass


if __name__ == "__main__":
    try:
        test2()
        test2()
        test1()
        test1()
        test1()
    except Exception as e:
        print(e)
    test2()
    test2()
    
"""
test2
test2
    test1      ： 1
    test1      ： 2
test1          
test2
test2
"""

함수 호출 횟수 에 대한 모니터링 과 함께 이 기능 을 사용 할 수 있 는 함 수 를 설정 했다.함수 호출 횟수 가 설정 밸브 값 을 초과 하면 이상 을 오래 던 집 니 다.다만 이곳 은 시간 에 제한 이 없다.
4.소스 코드 분석
방금 함수 호출 횟수 에 대한 제한 을 어떻게 실현 하 는 지 분 석 했 습 니 다.한 요청 에 있어 복잡 할 수 있 습 니 다.다음은 DRF 가 어떻게 실현 되 는 지 보 겠 습 니 다.

class SimpleRateThrottle(BaseThrottle):
   
    # ......
    
    def allow_request(self, request, view):
        """
        Implement the check to see if the request should be throttled.

        On success calls `throttle_success`.
        On failure calls `throttle_failure`.
        """
        if self.rate is None:
            return True

        self.key = self.get_cache_key(request, view)
        if self.key is None:
            return True

        self.history = self.cache.get(self.key, [])
        self.now = self.timer()

        #                   
        while self.history and self.history[-1] <= self.now - self.duration:
            self.history.pop()
        #               
        if len(self.history) >= self.num_requests:
            return self.throttle_failure()
        return self.throttle_success()
    
    # ......
    
class UserRateThrottle(SimpleRateThrottle):
    """
    Limits the rate of API calls that may be made by a given user.

    The user id will be used as a unique cache key if the user is
    authenticated.  For anonymous requests, the IP address of the request will
    be used.
    """
    scope = 'user'

    def get_cache_key(self, request, view):
        if request.user.is_authenticated:
            ident = request.user.pk
        else:
            #                AnonRateThrottle   key   
            ident = self.get_ident(request)
        #              key
        return self.cache_format % {
            'scope': self.scope,
            'ident': ident
        }

위 에서 말 한 바 와 같이:
4.567917.핵심 적 인 판단 논 리 는 캐 시 에서 모든 사용자 의 호출 횟수 를 가 져 오고 범위 와 시간 에 따라 설 정 된 밸브 값 을 초과 하 는 지 판단 하 는 것 이다

서로 다른 유형의 제한 흐름 은 캐 시 키 의 디자인 에 있어 차이 가 있 습 니 다.기본 키 는 요청 중의 REMOTE 입 니 다.ADDR。

5.기타 주의사항
4.567917.캐 시 를 사용 하기 때문에 여러 인 스 턴 스 가 배 치 된 상황 에서 통 일 된 캐 시 서 비 스 를 설정 해 야 합 니 다(기본 캐 시 는 Django 메모리 기반)4.567917.캐 시 서비스의 재 부팅 은 기 존의 계산 을 0 으로 만 들 수 있 습 니 다.비교적 강 한 업무 논리 적 수요 가 있 으 면 흐름 제한 논 리 를 스스로 실현 하 십시오사용자 정의 사용자 시트 라면 캐 시 에 있 는 get 을 다시 써 야 합 니 다.cache_key 의 논리4.567917.사용자 의 제한 상황 을 통계 분석 해 야 한다 면 제한 흐름 의 논 리 를 재 설계 해 야 한다4.567917.흐름 제한 논 리 는 생산 환경 에서 신중하게 사용 합 니 다.사용자 가 제품 을 사용 하 는 것 을 제한 하고 사용자 에 게 우호 적 이지 않 기 때 문 입 니 다참고 자료
DRF 제한 흐름
Django 캐 시
이상 은 Django REST framework 제한 기능 의 사용 에 대한 상세 한 내용 입 니 다.Django REST framework 제한 기능 에 관 한 자 료 는 다른 관련 글 을 주목 하 세 요!