0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · บทเรียน

การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง

กระจายทราฟฟิกไปยังเซิร์ฟเวอร์อย่างไม่เท่ากันด้วยค่าน้ำหนัก และเพิ่มเซิร์ฟเวอร์สำรองที่จะรับช่วงต่อเมื่อกลุ่มเซิร์ฟเวอร์หลักล้มเหลวเท่านั้น

การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง เป็นบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

When Servers Are Not Equal

Real upstream pools often mix machines of different capacity. A new 16-core server should not get the same share as an old 4-core box.

Nginx lets you bias traffic with weights so stronger servers handle more requests.

The weight Parameter

Add weight=N to a server. The default weight is 1. A server with weight=3 receives roughly three times as many requests as a weight=1 server.

upstream app {
    server 10.0.0.1 weight=3;
    server 10.0.0.2 weight=1;
}

How the Ratio Works

With weights 3 and 1, out of every 4 requests, 3 go to the first server and 1 to the second. Weights are relative, so 6 and 2 produce the same split as 3 and 1.

Weights with Other Algorithms

Weights work with round robin (the default) and least connections. They do not apply to ip_hash, which selects a server purely from the client IP.

upstream app {
    least_conn;
    server 10.0.0.1 weight=5;
    server 10.0.0.2 weight=2;
}

Introducing Backup Servers

A server marked backup receives no traffic while any primary server is available. It activates only when all primaries are down or unreachable.

upstream app {
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.9 backup;
}

Why Use a Backup

Backups give you a graceful fallback, for example a maintenance page server or a secondary data center, without sending it normal traffic during healthy operation.

Marking a Server Down

Use down to permanently remove a server from rotation, handy during planned maintenance without deleting the line.

upstream app {
    server 10.0.0.1;
    server 10.0.0.2 down;
}

Failure Detection Parameters

max_fails sets how many failed attempts mark a server unavailable, and fail_timeout sets the window and how long it stays out.

server 10.0.0.1 max_fails=3 fail_timeout=30s;

Combining Weight and Backup

You can mix weights for primaries and keep a single backup for the whole pool. The backup ignores weight until it is the only option.

upstream app {
    server 10.0.0.1 weight=4;
    server 10.0.0.2 weight=1;
    server 10.0.0.9 backup;
}

Limiting Connections

The max_conns parameter caps simultaneous connections to a server, protecting a weaker box even if its weight is high.

server 10.0.0.2 weight=2 max_conns=100;

Testing the Distribution

Fire many requests and check your access logs per upstream to confirm the ratio matches the weights. Adjust weights based on observed CPU and latency.

for i in $(seq 1 100); do curl -s http://localhost/ > /dev/null; done

Quick Check

A server is marked backup. When does it receive requests?

Recap

You learned to fine-tune traffic distribution:

  • weight=N biases traffic toward stronger servers
  • Weights are relative and apply to round robin and least_conn
  • backup servers activate only when primaries fail
  • down, max_fails, and max_conns control availability

Together these give you precise control over an uneven server fleet.

คำถามที่พบบ่อย

บทเรียน “การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง”

กระจายทราฟฟิกไปยังเซิร์ฟเวอร์อย่างไม่เท่ากันด้วยค่าน้ำหนัก และเพิ่มเซิร์ฟเวอร์สำรองที่จะรับช่วงต่อเมื่อกลุ่มเซิร์ฟเวอร์หลักล้มเหลวเท่านั้น คุณปฏิบัติ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) นี้ได้ไหม

ได้ บทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. อัลกอริทึมการกระจายโหลด
  2. การตรวจสอบสถานะและการเฝ้าติดตามเซิร์ฟเวอร์
  3. เซสชันแบบยึดติดและการคงอยู่ของเซสชัน
  4. การกระจายโหลดตามน้ำหนักและเซิร์ฟเวอร์สำรอง
← กลับไปที่ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)