상류의 nginx의 할당의 5 가지 방법이 현재 지원
1 폴링 (디폴트)
백 - 엔드 서버가 다운 된 경우, 각각 다른 시간 순서 백엔드 서버에 할당 된 각각의 요청은, 자동으로 제거 될 수있다.
{backserver 업스트림
서버 192.168.0.14]
서버 192.168.0.15]
}
2 중량 지정
폴링하여 케이스 불균일 백엔드 서버 성능에 대한 중량비 액세스 비례 확률.
{backserver 업스트림
서버 가중치 = 192.168.0.14 8].
서버 192.168.0.15 중량 = 10;
}
. 3 ip_hash에게 바인딩 IP
백엔드 서버로 각 게스트 액세스가 고정되어, 해시 결과 IP 분포의 각각의 액세스 요청이 해결 될 수 있도록 세션 문제.
{backserver 상류
ip_hash,
서버 192.168.0.14:88,
서버 192.168.0.15:80;
}
. (4) 공정 (제 3 자)
는 백엔드 서버, 짧은 응답 시간을 우선 순위 할당에 할당 요구의 응답 시간에 의해.
{backserver 업스트림
서버 서버 1,
서버 서버 2;
공정;
}
5 url_hash (제 3 자)
해시 결과에 URL이 할당 요청 동일한 백엔드 서버로 각각의 URL에 액세스하기 위해, 백엔드 서버는 캐시 때 효과적이다.
{backserver 업스트림
: 3128, 서버 squid1
서버 squid2 : 3128,
해시 $ REQUEST_URI,
hash_method의 CRC32;
}
을 필요로 균형 서버 부하 증가
proxy_pass HTTP : // backserver /;
상류 backserver {
; ip_hash
서버 127.0.0.1:9090 아래로 (아래 일시적으로 참여하지 않는 현재의 서버의 부하를 나타낸다)
서버에게 127.0.0.1:8080 중량 = 2 (기본 중량이 큰 1.weight는, 큰 부하 질량의 중량)
서버 127.0.0.1:6060,
서버 127.0.0.1 : 7070 백업 (다른 모든 백업 시스템 다운 또는 비 바쁜 시간은 백업 시스템을 요청)
}
max_fails을 : 수가 최대 값을 초과 1. 실패한 요청 디폴트의 허용 번호, 모듈 반환 정의 proxy_next_upstream 오류
fail_timeout을 : max_fails 실패를 일시 정지 시간 후
통찰력 :
1 소개
연속 증가 웹 사이트 부하 밸런싱 (부하 분산)을로드 익숙하지 않은 주제되지 않습니다. 트래픽로드 밸런싱로드는 고 가용성 서버를 보장하기 위해 사용자에게 좋은 경험을 제공하기에 충분한 빠른 응답을 보장하기 위해 다른 서비스 단위로 할당된다.
nginx를 첫 공개 버전은 2004 년에 발표되었다. 2011, 버전 1.0을 발표했다. 그것은 높은 안정성, 강력 낮은 자원 사용을 특징으로한다. 보기의 nginx와 아파치 경쟁의 서버 시장 점유율의 관점에서 추진력을 가지고 있습니다. 그 중, 특성이 언급해야하는 것은 많은 회사를 선택하는 주된 이유가되었다의로드 밸런싱 기능입니다.
우리는 내장로드로드 밸런싱을 예로 들어 실제 산업 생산 전략과 확장 전략을 균형, 각로드 밸런싱 전략을 비교 일부 참조 nginx를 사용자에게 제공의 nginx에 대한 관점을 소스 것이다.
2. 소스 분석
내장 된 정책과 확장 전략 : nginx를로드 밸런싱 전략은 두 가지 범주로 나눌 수 있습니다.
내장 정책은이 두 가지 전략의 기본에, WRR 및 IP 해시를 포함하는 커널 컴파일의 nginx 것입니다, 당신은 단순히의 nginx 구성 매개 변수를 지정할 수 있습니다. 이 등 공정, 보편적 인 해시 일관된 해시, 많은 확장 전략은이다 nginx를 커널에 컴파일 기본하지 않습니다.
버전의 코드는 다음과 같은 예를 들어, 안정 버전을 nginx1.0.15 있도록, 자연의 본질을 변경하지 않습니다 nginx를로드 밸런싱을 업그레이드하기 때문에, 소스의 관점에서 다양한 전략을 분석 할 수 있습니다.
2.1. WRR (가중 라운드 로빈)
폴링 원리는 매우 간단합니다, 우리는 먼저 폴링의 기본 프로세스를 소개합니다. : 후속 요청을 도시하는 흐름도이다 
도 두 점에 유의해야한다 :
가중 라운드 로빈 알고리즘은 우선 탐색 및 다양한 깊이 우선 탐색으로 분할 될 수있는 경우 먼저, 다음의 nginx 즉 제, 깊이 우선 탐색 알고리즘을 사용하여 요청이 아래로 다른 기계보다 낮은에 기계의 무게까지, 기계의 높은 무게 분산, 높은 무게 기계 아래의 요청에 부여하기 시작했다.
장비의 뒤쪽 끝이 아래로 모든 가을 때 둘째, 즉시 Nginx의 모든 시스템 플래그가 살 수있는 램의 전체 프론트 엔드를 일으키는 모든 머신이 타임 아웃 상태에있는 것을 방지하기 위해 초기 상태로 삭제됩니다.
그런 다음 소스 코드를 보면. Nginx의 디렉토리 구조는 매우 분명하다, 가중 라운드 로빈 경로는 nginx에-1.0.15하는 / SRC / HTTP / ngx_http_upstream_round_robin. [C | 시간을, 소스 코드에 기초하여, 중요한 어렵 위해 내가 메모를 추가 위치를 이해하기. 중요한 문 ngx_http_upstream_round_robin.h에서 먼저보기 : 
변수 이름에서 대략 그 효과를 추측 할 수 있습니다. Current_weight 동적 변경 요청의 처리와 무게의 차이는 이전의 정렬 가중치를 설명에서는, 후자의 값은 초기 상태를 복원하도록 구성된다.
우리는 폴링의 창조에서보기로했다. 다음과 같이도 코드는 
시도 변수 설명을 할 필요가있다 : 현재를 통해 연결을 시도하는 서버에 기록했습니다. 그는 비트 맵입니다. 서버의 수 미만 32 인 경우, 단순히 INT의 상태에서 모든 서버를 기록합니다. 수는 서버 (32)보다 큰 경우, 응용 프로그램이 메모리 풀을 저장하기 위해 메모리가 필요합니다.
비트 맵 배열 코드는 다음을 참조하여 
마지막으로, 실제 정책 코드, 로직은 비교적 단순 코드의 30 라인을 달성하는 것이다. 코드를 봐. 
2.2. IP를 해시 정책
의 IP 해시 nginx를 다른 내장 된로드 밸런싱 전략, 프로세스 및 폴링과 매우 유사하지만, 이러한 변화 알고리즘과 특정 전략의 일부. 아래와 같이 
코어 IP는 다음과 같은 코드를 달성하기 위해 해시 알고리즘을 참조 : 
참조, 시스템 관련의 후단의 IP 관련 번호 모두의 해시 값. 테스트 후, 상기 알고리즘은 연속적 알고리즘 하드 한계 값 서로로부터 1,045 가지를 생성 할 수있다. 전달 20 시간을 사용할 수 기계, 폴링으로 알고리즘의 퇴화를 찾을 수 없습니다 아직 해시 때의 nginx는 보호 메커니즘을 사용합니다.
처음 두 개의 IP 해시 값은 다음 두 IP에서 요청이 항상 동일한 서버에 떨어질 것이다, 정확히 같은 경우 그래서, 본질적으로, IP 해시 알고리즘은 폴링 알고리즘의 위장 된 형태이며, 이것은 균형 깊은 문제를 심었습니다.
2.3. 공정
공정 전략은 확장 전략의 nginx의 기본값은 커널에 컴파일되지 않고있다. 가벼운 부하 션트 기계를 선택,로드 백 엔드 서버의 응답 시간에 따라 결정됩니다.
이 전략은 강한 적응성을 가지고 있지만, 실제 네트워크 환경은 종종 그렇게 간단하지 않다, 따라서주의해서 사용해야합니다.
2.4 일반 해시, 해시 일관성
유니버설 해시 및 해시 일관성 확장 전략의 일종이다. Nginx에 보편적 인 해시 해시 링 memcache를 지원 일관성 일관성 내장 해시의 nginx를 사용하여 해시 키 변수를 구축 할 수있다.
(3) 비교 테스트
了解了以上负载均衡策略，接下来我们来做一些测试。
主要是对比各个策略的均衡性、一致性、容灾性等，从而分析出其中的差异性，根据数据给出各自的适用场景。
为了能够全面、客观的测试nginx的负载均衡策略，我们采用两个测试工具、在不同场景下做测试，以此来降低环境对测试结果造成的影响。
首先给大家介绍测试工具、测试网络拓扑和基本之测试流程。
3.1 测试工具
3.1.1 easyABC
easyABC是百度内部开发的性能测试工具，培训采用epool模型实现，简单易上手，可以模拟GET/POST请求，极限情况下可以提供上万的压力，在团队内部得到广泛使用。
由于被测试对象为反向代理服务器，因此需要在其后端搭建桩服务器，这里用nginx作为桩Web Server，提供最基本的静态文件服务。
3.1.2 polygraph
polygraph是一款免费的性能测试工具，以对缓存服务、代理、交换机等方面的测试见长。它有规范的配置语言PGL（Polygraph Language），为软件提供了强大的灵活性。其工作原理如下图所示：
polygraph提供Client端和Server端，将测试目标nginx放在二者之间，三者之间的网络交互均走http协议，只需配置ip+port即可。
Client端可以配置虚拟robot的个数以及每个robot发请求的速率，并向代理服务器发起随机的静态文件请求，Server端将按照请求的url生成随机大小的静态文件做响应。
选用这个测试软件的一个主要原因：可以产生随机的url作为nginx各种hash策略key。
另外polygraph还提供了日志分析工具，功能比较丰富，感兴趣的同学可以参考附录材料。
3.2. 测试环境
本次测试运行在5台物理机。其中：被测对象单独搭在一台8核机器上，另外四台4核机器分别搭建了easyABC、webserver桩和polygraph。如下图所示：
3.3. 测试方案
给各位介绍一下关键的测试指标：
均衡性：是否能够将请求均匀的发送给后端
一致性：同一个key的请求，是否能落到同一台机器
容灾性：当部分后端机器挂掉时，是否能够正常工作
以上述指标为指导，我们针对如下4个测试场景分别用easyABC和polygraph测试：
场景1 server_*均正常提供服务；
场景2 server_4挂掉，其他正常；
场景3 server_3、server_4挂掉，其他正常；
场景4 server_*均恢复正常服务。
上述四个场景将按照时间顺序进行，每个场景将建立在上一个场景基础上，被测试对象无需做任何操作，以最大程度模拟实际情况。
另外，考虑到测试工具自身的特点，在easyabc上的测试压力在17000左右，polygraph上的测试压力在4000左右。以上测试均保证被测试对象可以正常工作，且无任何notice级别以上（alert/error/warn）的日志出现，在每个场景中记录下server_*的qps用于最后的策略分析。
3.4. 结果
对比在两种测试工具下的测试结果会发现，结果完全一致，因此可以排除测试工具的影响。表1和图1是轮询策略在两种测试工具下的负载情况。
从图表中可以看出，轮询策略对于均衡性和容灾性都可以做到较好的满足。
表2和图2是fair策略在两种测试工具下的负载情况。fair策略受环境影响非常大，在排除了测试工具的干扰之后，结果仍然有非常大的抖动。
从直观上讲，这完全不满足均衡性。但从另一个角度出发，恰恰是由于这种自适应性确保了在复杂的网络环境中能够物尽所用。因此，在应用到工业生产中之前，需要在具体的环境中做好测试工作。
以下图表是各种hash策略，所不同的仅仅是hash key或者是具体的算法实现，因此一起做对比。实际测试中发现，通用hash和一致性hash均存在一个问题：当某台后端的机器挂掉时，原有落到这台机器上的流量会丢失，但是在ip hash中就不存在这样的问题。
正如上文中对ip hash源码的分析，当ip hash失效时，会退化为轮询策略，因此不会有丢失流量的情况。从这个层面上说，ip hash也可以看成是轮询的升级版。
图5为ip hash策略，ip hash是nginx内置策略，可以看做是前两种策略的特例：以来源IP为key。
由于测试工具不太擅于模拟海量IP下的请求，因此这里截取线上实际的情况加以分析。如下图所示：
图5 IP Hash策略
图中前1/3使用轮询策略，中间段使用ip hash策略，后1/3仍然是轮询策略。可以明显的看出，ip hash的均衡性存在着很大的问题。
原因并不难分析，在实际的网络环境中，有大量的高校出口路由器ip、企业出口路由器ip等网络节点，这些节点带来的流量往往是普通用户的成百上千倍，而ip hash策略恰恰是按照ip来划分流量，因此造成上述后果也就自然而然了。
4 小结
通过实际的对比测试，我们对nginx各个负载均衡策略进行了验证。下面从均衡性、一致性、容灾性以及适用场景等角度对比各种策略。如下图示：
我们从源码和实际测试数据角度分析说明了nginx负载均衡的策略，给出了各种策略适合的应用场景。通过分析不难发现，无论哪种策略都不是万金油，在具体场景下应该选择哪种策略一定程度上依赖于使用者对策略的熟悉程度。
以上分析和测试数据能够对大家有所帮助，期待有更多越来越好的负载均衡策略涌现，造福更多运维开发同学。
参考：