Bagaimana untuk mengkonfigurasi pengimbangan beban nginx

Polling

nginx mengedarkan semua permintaan secara sama rata kepada setiap pelayan dalam kelompok.

upstream test {
server 127.0.0.1:7001; # 等同于server 127.0.0.1:7001 weight=1;server 150.109.118.85:7001; # 等同于server 150.109.118.85:7001 weight=1;}

server {
listen 8081;
server_name localhost;

location / {
 proxy_pass http://test/;
}
}

hulu: Tentukan kluster perkhidmatan. proxy_pass: Majukan proksi permintaan yang sepadan kepada perkhidmatan yang dikonfigurasikan di belakang proxy_pass Memandangkan pengimbangan beban perlu dikonfigurasikan di sini, http:// mesti diikuti oleh kluster perkhidmatan yang ditakrifkan oleh huluan.

Nota: Apabila huluan mentakrifkan kluster perkhidmatan, alamat perkhidmatan yang dikonfigurasikan hanya boleh menjadi nama domain + port atau ip + port, dan tidak boleh mengandungi protokol dan laluan, jika tidak, nginx akan melaporkan nginx: [emerg] invalid host in upstream maklumat ralat ini.

Berat

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

Dua permintaan pertama akan dimajukan ke perkhidmatan 127.0.0.1:7001, permintaan seterusnya akan dimajukan ke perkhidmatan 150.109.118.85:7001 dan dua permintaan seterusnya akan dimajukan kepada 127.0.0.1:7001,. . .

Bilangan sambungan minimum

Lokasi fail: src/http/modules/ngx_http_upstream_least_conn_module.c

permintaan nginx diperuntukkan kepada pelayan dengan sambungan_aktif/berat terkecil.

upstream test {
  least_conn;
server 127.0.0.1:7001 weight=1;
server 150.109.118.85:7001 weight=1;
}

ip_hash

Lokasi fail: src/http/modules/ngx_http_upstream_ip_hash_module.c

Kira nilai cincang berdasarkan ip pengguna, jika terdapat pelayan yang sepadan dengan cincang ini dalam cache pengimbangan beban, ia akan dimajukan terus ke pelayan yang sepadan.

upstream test {
  ip_hash;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

Selepas nginx menggunakan dasar ip_hash, selagi IP komputer pengguna tidak berubah, ia akan sentiasa meminta perkhidmatan perniagaan yang sama.

Senario aplikasi: Apabila melaksanakan fungsi muat naik fail, untuk memuat naik fail besar, fail besar selalunya dibahagikan kepada berbilang serpihan dan kemudian dimuat naik ke pelayan Jika strategi yang diberikan di atas digunakan, masalah yang sama akan berlaku berlaku. Serpihan fail telah dimuat naik ke pelayan yang berbeza, menyebabkan penggabungan fail gagal dan hasil yang diharapkan tidak dapat dicapai. Selepas nginx menggunakan dasar ip_hash, pelanggan hanya perlu memuat naik serpihan fail semasa Apabila serpihan fail berikutnya dimuat naik, nginx secara automatik memajukan permintaan ke pelayan yang sepadan dengan cincangan dengan mengira cincangan IP.

cincang

Lokasi fail: src/http/modules/ngx_http_upstream_hash_module.c

Remote_addr (ip pelanggan) yang boleh digunakan untuk pengiraan cincang (lihat keputusan ujian) Anda boleh terus menggantikan ip_hash), request_uri (request uri), dan args (parameter permintaan yang berikut terutamanya menggunakan penggunaan request_uri sebagai demonstrasi.

Kira nilai cincang berdasarkan uri yang diminta, dan kemudian majukan permintaan ke pelayan Selepas permintaan seterusnya dikira melalui cincang, jika terdapat cincang yang sama, permintaan itu akan dimajukan ke cincang. Pelayan yang sepadan.

Anggapkan apa yang akan berlaku jika pelayan dalam kluster turun: Jika r1 mencecah pelayan a, pelayan yang manakah akan r2 terkena? . Jika pelayan a turun, korespondensi antara nilai cincang yang dikira sebelum ini oleh r1 dan pelayan a akan menjadi tidak sah, dan r1 akan diedarkan semula ke pelayan b. Selepas pelayan a kembali normal, r1 masih akan diberikan kepada pelayan b.

upstream test {
  hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

Senario aplikasi: Semua permintaan untuk sumber fail yang sama akan dimajukan ke pelayan yang sama, menjadikannya lebih mudah untuk sumber mencapai cache, mengurangkan lebar jalur dan masa muat turun sumber.

consistent_hash

consistent_hash (consistent hash) Modul ini digunakan dalam cara yang hampir sama seperti modul cincang terbina dalam nginx. Kandungan yang boleh dikira menggunakan consistent_hash adalah sama dengan modul cincang terbina dalam nginx yang dinyatakan sebelum ini, termasuk remote_addr, request_uri dan args. Anda boleh memuat turun ngx_http_consistent_hash di sini, yang merupakan perisian untuk modul pihak ketiga.

upstream test {
consistent_hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

adil

Permintaan perkhidmatan dengan masa respons yang singkat diutamakan. Anda boleh mendapatkan modul pihak ketiga ini daripada halaman muat turun nginx_upstream_fair. Modul ini kali terakhir dikemas kini 8 tahun yang lalu Anda mungkin ingin mempertimbangkan sama ada anda perlu menggunakan ini.

upstream test {
fair;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

Dalam ujian, kesannya adalah sama seperti situasi pengundian lalai, dan masalahnya belum ditemui lagi. . .

Parameter berkaitan pengimbangan beban

turun

Pelayan yang dikenal pasti oleh down buat sementara waktu tidak menyokong permintaan sumber.

upstream test {
server 127.0.0.1:7001 down;
server 150.109.118.85:7001;
}

Dalam contoh pengimbangan beban di atas, kerana 127.0.0.1:7001 ditandakan sebagai down, tiada permintaan akan dimajukan kepada perkhidmatan ini. Semua permintaan akan dimajukan ke perkhidmatan 150.109.118.85:7001.

berat

Nilai berat perkhidmatan dalam gugusan, lalai ialah 1. Di bawah syarat bahawa hanya berat yang terjejas, dan semua perkhidmatan dalam kelompok adalah normal, nginx akan memajukan lebih banyak permintaan kepada perkhidmatan dengan berat yang lebih besar.

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

Nisbah permintaan yang diproses oleh perkhidmatan 127 dan perkhidmatan 150 dalam kelompok ini ialah 2:1.

max_fails

Bilangan ralat perkhidmatan yang dibenarkan apabila perkhidmatan memproses permintaan, lalainya ialah 1. Apabila bilangan ralat dalam permintaan pemprosesan perkhidmatan melebihi max_fails, permintaan berikutnya tidak akan dimajukan kepada perkhidmatan di mana ralat itu berlaku.

upstream test {
server 127.0.0.1:7001 max_fail=1;
server 150.109.118.85:7001;
}

fail_timeout

如果某个服务处理请求时发生错误的次数超过 max_fails，nginx 将暂时禁止将请求转发到该服务。当过去fail_timeout设置的时间以后，nginx会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待fail_timeout时间后再来检测。fail_timeout默认时间是10s。

upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}

backup

备用服务器，当所有非backup服务发生错误被停用或者设置为down时，nginx会启用标识为backup的服务。

upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}

max_conns

这个功能存在于nginx商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。

upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}

slow_start

这个功能存在于nginx商业版。当集群中错误服务等待fail_timeout时间后，nginx检测到这个服务能够正常使用后，再等待slow_start时间后，才正式使用这个服务。

upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}

Atas ialah kandungan terperinci Bagaimana untuk mengkonfigurasi pengimbangan beban nginx. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!