묘사 하 다. 1. Dubbo 부하 균형: 4 가지 (랜 덤, 순환, 최소 활성, hash) 를 지원 하고 JVM 예열 시간 가중, 사용자 정의 설정 규칙 을 도입 하 는 동시에 콘 솔 동적 설정 가중치 파 라미 터 를 지원 하기 때문에 가장 유연 합 니 다. 2. Nginx 부하 균형: 4 가지 지원, 자체 폴 링 (가중치 지원), IPHash (Session 공유 문 제 를 피하 기), 최소 연결 수 정책, fair (응답 시간) 정책 을 확장 하고 기능 에 더욱 집중 할 수 있 습 니 다. 3. Ribbon 부하 균형: 6 가지 지원, 가중치 지원 하지 않 음: 폴 링, 랜 덤, 최소 연결 수, 최 단 응답 시간 (랜 덤 + 응답 시간 가중), 여과 이상 노드 + 폴 링, 부하 전략 이 가장 완전한 Dubbo 부하 균형 (2.6. x) Dubbo 는 4 가지 부하 균형 알고리즘 을 제공 하여 JVM 예열 시간 가중, 가중치 사용자 정의 설정 규칙 을 도입 하 는 동시에 콘 솔 동적 설정 가중치 파 라미 터 를 지원 하기 때문에 가장 유연 합 니 다.
Random LoadBalance: 가중치 에 따라 Provider 를 무 작위 로 분배 합 니 다. 예 를 들 어 무 작위 로 Node 1: Node 2 = 2: 1 을 중시 하면 30 번 운행 합 니 다. 약 20 번 은 Node 1 에서, 10 번 은 Node 2 에서 실 행 됩 니 다.
RoundRobin LoadBalance: 가중치 폴 링 에 따라 분배 합 니 다.예 를 들 어 가중치 Node 1: Node 2 = 20: 10, 그러면 30 회 실행: 앞의 20 번 에서 Node 1 과 Node 2 를 각각 10 번, 20 번 에서 30 번, 모두 Node 1 을 선택 합 니 다.Dubbo 는 기본적으로 공약수 처 리 를 하지 않 기 때문에 완전한 20 + 10 회 연산 을 완성 해 야 부하 균형 의 가중치 비례 가 정확 하 다. 만약 Consumer 가 20 회 만 호출 했다 면 여기 서 설정 한 가중치 의 결 과 는 1: 1 이 고 이 알고리즘 은 매우 부 드 럽 지 않다.2.6.5 버 전에 서 복 구 했 습 니 다. Nginx 의 실현 방법 과 같 습 니 다.
LeastActive LoadBalance: 노드 처리 가 빠 를 수록 더 많이 분배 되 고 느 린 노드 가 쌓 이지 않도록 합 니 다. Provider 를 선별 할 때마다 Active 값 이 가장 작은 노드 만 취하 고 최소 Active 값 의 노드 가 여러 개 있 으 면 가중치 에 따라 무 작위 로 선택 합 니 다.Provider 는 작업 Active 값 + 를 가 져 올 때마다 작업 Active 값 을 끝 낼 때마다 --.
ConsistentHash LoadBalance: 가중치 설정 과 JVM 예열 을 무시 하 는 유일한 알고리즘 입 니 다.먼저 모든 Provider 를 160 개의 가상 노드 로 분배 하고 Hash 알고리즘 을 통 해 모두 Hash 원 에 분산 시 킵 니 다.Consumer 가 호출 될 때마다 매개 변수 값 에 따라 Hash 환산 을 하고 마지막 으로 Hash 원 에 비 추어 인근 가상 노드 를 찾 아 서 비 스 를 제공 하 는 Provider 를 가 져 옵 니 다.그러나 Dubbo 는 이 를 실현 할 때 Hash 일치 성 원칙 에 어 긋 나 Porvider 가 변 경 될 때마다 (추가 또는 제거) Hash 원 을 다시 만 듭 니 다. 이전 Hash 원 에 불합격 한 Porvider 를 추가 하거나 제거 하 는 것 이 아 닙 니 다.
Nginx 부하 균형 알고리즘 Nginx 는 현재 4 가지 부하 균형 설정 이 있 습 니 다.
round robin, 가중 폴 링 은 기본 HTTP 부하 균형 알고리즘 으로 기계 의 성능 을 알 고 있 으 며, 기본 모든 요청 은 서버 에 있어 서 처리 시간 차이 가 크 지 않 습 니 다. 예 를 들 어 제 Server 1 은 Server 2 의 설정 보다 배가 높 습 니 다. 저 는 2: 1 의 가중치 로 설정 하여 비교적 과학적 인 부하 가 가능 합 니 다. 알고리즘 실현 에 있어 서 간단 한 폴 링 은 간단 합 니 다. Ser 마다ver 순서대로 번 호 를 매 긴 다음 에 하나의 호출 index 만 기록 하면 폴 링 을 실현 할 수 있 습 니 다.
ip hash, IP 해시, 세 션 유지 가능
least conn; 느 린 축적 을 피하 고 연결 수가 가장 작은 server 를 이용 하여 서 비 스 를 제공 합 니 다. 일부 요청 이 오래 걸 리 거나 시간 이 걸 리 는 경 우 를 피 할 수 있 습 니 다. 실제 연결 수 에 따라 서버 를 선택 하 십시오.
fair 는 플러그 인 이 이 기능 을 확장 해 야 합 니 다. 백 엔 드 서버 의 응답 시간 에 따라 요청 을 분배 하고 응답 시간 이 짧 은 우선 분 배 를 하여 느 린 축적 을 피해 야 합 니 다.
가중치 설정: 또한 부 드 러 운 부하 균형 알고리즘 을 사용 합 니 다. 예 를 들 어 node 1: node 2: node 3 = 1: 2: 5 -- > node 3, node 3, node 2, node 3, node 1, node 3, node 2, node 3. 리본 부하 균형 개술
RoundRobin Rule: 폴 링. 기본적으로 10 번 이상 받 은 server 를 사용 할 수 없습니다. 빈 server
를 되 돌려 줍 니 다.
RandomRule: 무 작위 입 니 다. 무 작위 로 도착 한 server 가 null 이거 나 사용 할 수 없 으 면 while 의 끊 임 없 는 순환 선택
Retry Rule: 일정 기간 동안 순환 재 시도 합 니 다. RoundRobin Rule 을 기본 으로 계승 하고 사용자 정의 주입 도 지원 합 니 다. Retry Rule 은 매번 선택 한 후에 선거의 server 에 대해 null 인지, alive 인지, 그리고 500 ms 내 에 끊임없이 선택 하여 판단 합 니 다. RoundRobin Rule 의 실효 전략 은 10 회 를 넘 는 것 이 고 RandomRule 은 실효 시간 이 없다 는 개념 입 니 다. server Lis 만 있 으 면 됩 니 다.t. 다 안 끊 었 어 요.
@Bean
public IRule ribbonRule() {
return new RetryRule(new BestAvailableRule());// ，
}
BestAvailableRule: 최소 연결 수 입 니 다. server List 를 옮 겨 다 니 며 사용 가능 하고 연결 수가 가장 작은 server 를 선택 하 십시오. 이 알고리즘 에는 LoadBalancer Stats 의 구성원 변수 가 있 습 니 다. 모든 server 의 실행 상황 과 연결 수 를 저장 합 니 다. 선택 한 server 가 null 이면 RoundRobinRule 로 다시 선택 합 니 다.
Weighted ResponseTimeRule: 최소 응답 시간 입 니 다. 이 정책 은 무 작위 알고리즘 과 응답 시간 가중 알고리즘 을 통합 합 니 다. 정시 작업 을 시작 합 니 다. 30 초 마다 모든 Provider 의 응답 시간 을 계산 합 니 다. 응답 시간 을 가중치 로 합 니 다. 응답 시간 이 짧 을 수록 서버 가 선 택 될 확률 이 높 습 니 다. 예 를 들 어 Node 1: node 2: node 3 의 평균 응답 시간 은 100 ms: 200 ms: 300 ms 입 니 다.nodes 의 가중치 는 300: 500: 600 이 고 매번 600 을 바탕 으로 * 랜 덤 값 입 니 다. 그러면 0 - 300 에 떨 어 질 확률 은 50% 이 고 300 - 500 의 확률 은 33% 이 며 100 - 600 의 확률 은 17% 입 니 다. 즉, 평균 응답 시간 이 짧 은 노드 일수 록 선 택 될 확률 이 높 습 니 다.
double totalResponseTime = 0;
//
for (Server server : nlb.getAllServers()) {
ServerStats ss = stats.getSingleServerStat(server);
totalResponseTime += ss.getResponseTimeAvg();
}
Double weightSoFar = 0.0;
// weightSoFar， weight - ， ，node ，weight ，
List finalWeights = new ArrayList();
for (Server server : nlb.getAllServers()) {
ServerStats ss = stats.getSingleServerStat(server);
double weight = totalResponseTime - ss.getResponseTimeAvg();
weightSoFar += weight;
finalWeights.add(weightSoFar);
}
setWeights(finalWeights);
Availability FilteringRule 여과 + 폴 링 전략 은 고장 이 나 거나 동시 다발 요청 이 한도 값 보다 큰 일부 서비스 인 스 턴 스 를 거 른 다음 에 폴 링 합 니 다.
Zone Avoidance Rule 은 폴 링 정책 을 확장 하여 2 개의 필 터 를 계승 했다. Zone Avoidance Predicate 와 Availability Predicate 는 시간 초과 와 링크 수가 너무 많은 server 를 걸 러 내 는 것 외 에 요구 에 부합 되 지 않 는 zone 안의 모든 노드 를 걸 러 낸다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
