Cân bằng tải là gì

Cân bằng tải, tên tiếng anh là Load Balance, có nghĩa là cân bằng tải (các nhiệm vụ công việc) và phân bổ cho nhiều đơn vị vận hành để vận hành.

Sau đây là phần giới thiệu về một số chiến lược cân bằng tải.

1. Ngẫu nhiên

Khi mọi người nói về cân bằng tải ngẫu nhiên, họ thường nghĩ đến Round Robin. Trên thực tế, Round Robin không phải là ngẫu nhiên.

Random thực sự là ngẫu nhiên, phân bổ ngẫu nhiên các yêu cầu đến máy chủ dựa trên thuật toán ngẫu nhiên.

• lợi thế:

  • Với khả năng chịu tải

• thiếu sót:

  • Bị ảnh hưởng bởi thuật toán ngẫu nhiên, tải của mỗi máy chủ không thể cân bằng được.
  • Nó không thể tự điều chỉnh theo tải của máy chủ nên hiếm có chiến lược ngẫu nhiên thực sự đơn giản như vậy.

2. Vòng tròn

Như đã đề cập ở trên, bỏ phiếu thực sự là một chiến lược trung bình, không phải là một chiến lược ngẫu nhiên.

Nội dung chiến lược cụ thể của nó như sau:

Bộ cân bằng tải có danh sách các máy chủ, .

Nó sẽ sắp xếp chúng để tạo thành một danh sách tuần tự cố định từ 1 đến N.

Mỗi khi yêu cầu được thực hiện, một đồng chí máy chủ chưa đến lượt sẽ được chọn từ hàng đợi để nhận nhiệm vụ yêu cầu.

Khi toàn bộ hàng đợi đã chấp nhận nhiệm vụ, một vòng xếp hàng nhiệm vụ mới sẽ bắt đầu lại từ đầu.

Và tại sao người ta thường nói đó là chiến lược ngẫu nhiên?

Chủ yếu đối với client yêu cầu, server yêu cầu lần này và lần sau không nhất thiết phải là cùng một server nên có vẻ ngẫu nhiên.

• lợi thế:

  • Tải rất đều

• thiếu sót:

  • Không thể điều chỉnh tải dựa trên sự khác biệt của máy chủ (chẳng hạn như hiệu suất)
  • Vì nó bắt đầu theo trình tự 1 nên nếu có một lượng lớn lưu lượng truy cập đồng thời ở đầu thì có nguy cơ trạm đầu tiên sẽ bị đánh bại.

3. Kết nối ít nhất

Chúng ta có thể dễ dàng hiểu ngay từ cái tên, .

Chiến lược của nó rất đơn giản: nó sử dụng máy chủ có số lượng kết nối nhỏ nhất mỗi lần.

• lợi thế:

  • Có khả năng cân bằng tài nguyên linh hoạt theo sự thay đổi về số lượng kết nối
  • Trong các tình huống có nhiều kết nối dài (chẳng hạn như ftp), việc phân bổ tài nguyên là rất hợp lý

• thiếu sót:

  • Tuy nhiên, trong trường hợp có sự khác biệt về tài nguyên máy chủ thì số lượng kết nối không thể bù đắp được sự khác biệt này.
  • Trong kịch bản thêm và xóa động danh sách máy chủ, yêu cầu sẽ đánh vào máy chủ mới được thêm và lưu lượng lớn có thể dễ dàng đánh bại máy chủ này (nói chung, chiến lược khởi động chậm sẽ được sử dụng để giảm tải tương ứng và giảm thiểu rủi ro)

4.Băm

Các chiến lược cân bằng tải khác phù hợp với các dịch vụ không trạng thái.

Chỉ Hash mới giải quyết cụ thể vấn đề cân bằng tải của các dịch vụ có trạng thái.

Chiến lược cụ thể của nó được minh họa bằng cách tiếp cận đơn giản:

Ví dụ: hàm băm ip hoặc url sẽ sử dụng chuỗi ip hoặc url để tính giá trị số nguyên cố định dựa trên thuật toán băm.

Sau đó sử dụng giá trị số nguyên để tính xem máy nào tương ứng với số lượng máy chủ.

Điều này tạo ra một hiệu ứng dính.

• lợi thế:

  • Đã giải quyết vấn đề các dịch vụ có trạng thái không thể cân bằng tải

• thiếu sót:

  • Máy chủ đang ngoại tuyến, điều này có thể khiến một số máy dính vẫn truy cập được vào máy bị lỗi (nói chung, máy ngoại tuyến sẽ được xác định thông qua kiểm tra tình trạng và sau đó máy dính sẽ được băm lại)
  • Nếu sử dụng chiến lược thuật toán có độ dính băm lại, phía doanh nghiệp cần xử lý nó để tránh tác động của nó. Ví dụ: dữ liệu không thể chỉ được đặt trên máy chủ cố định.

5. EWMA

Đối với tôi, có vẻ như phương pháp này lần đầu tiên được nhìn thấy trong Finagle (thư viện RPC máy khách của Twitter).

Về mặt lý thuyết, khi máy chủ không đủ sức mạnh tính toán CPU, card mạng quá tải, không đủ cổng, v.v., thời gian phản hồi sẽ lâu hơn đáng kể.

Sau đó, sự thay đổi về độ trễ phản hồi có thể được sử dụng để đánh giá tải của máy chủ và tình hình của chính máy chủ ở một mức độ nhất định.

Ý tưởng của EWMA là đo lường những thay đổi về độ trễ yêu cầu để tối ưu hóa hiệu quả cân bằng tải một cách linh hoạt.

Nói một cách đơn giản, EWMA giữ mức trung bình động của thời gian khứ hồi cho mỗi yêu cầu máy chủ, được tính theo số lượng yêu cầu chưa xử lý và phân bổ lưu lượng truy cập đến máy chủ có hàm chi phí nhỏ nhất.

Nói chung, chiến lược P2C cũng được sử dụng kết hợp với EWMA để tránh tấn công cùng một máy chủ cùng một lúc. (P2C chọn ngẫu nhiên hai máy chủ, so sánh giá trị EWMA của chúng và lấy giá trị nhỏ nhất).

linkerd đã thực hiện kiểm tra cân bằng tải và kết quả (tất nhiên không nhất thiết phải thể hiện kết quả thực tế).

• lợi thế:

  • Thuật toán có thể điều chỉnh động tình trạng tải tốt hơn theo các điều kiện thay đổi.

• thiếu sót:

  • Bản thân kịch bản kinh doanh là tình huống có độ trễ cao, chẳng hạn như bỏ phiếu dài và thuật toán này không thể đo được tải của máy chủ.

Lưu ý đặc biệt về trọng lượng

Nói đúng ra, trọng lượng hiếm khi được sử dụng như một chiến lược cân bằng tải riêng biệt.

Nó thường được kết hợp với các chiến lược cân bằng tải khác nhau được đề cập ở trên.

Mục đích của việc tính trọng số chủ yếu là để giải quyết cách chúng ta có thể đặt trước việc phân bổ tài nguyên tốt hơn khi chúng ta biết hoặc có thể ước tính khả năng tải của máy chủ.

Vì vậy hiện nay các thuật toán cân bằng tải này thường cung cấp các thông số trọng lượng để mọi người có thể đặt trước tỷ lệ tải.

Một số thậm chí còn cố gắng sử dụng máy học và các phương tiện khác để điều chỉnh linh hoạt các thông số trọng lượng nhằm điều chỉnh điều kiện tải tài nguyên nhanh hơn.

Thực hiện đơn giản Round Robin

Do hạn chế về không gian, tôi sẽ không giải thích cách triển khai từng cái ở đây mà chỉ giới thiệu Round Robin.

Nội dung sau đã được cập nhật lên openresty-dev-1.rockspec.

                            
                              -- phụ thuộc = { "lua-resty-balancer >= 0,04", }
                            
                          

Sau đó thực hiện.

                            
                              luarocks cài đặt openresty-dev-1.rockspec --tree=deps --only-deps --local
                            
                          

Mã demo cụ thể như sau:

                            
                              worker_processes 1; #nginx worker sẽ ghi lại error_log logs/error.log; #Thông báo lỗi thời gian thực hiện events { worker_connections 1024; } http { log_format main '$remote_addr [$time_local] $status $request_time $upstream_status $upstream_addr $upstream_response_time'; access_log logs/access.log main buffer=16384 flush=3; #access_log 文件配置 lua_package_path "$prefix/deps/share/lua/5.1/?.lua;$prefix/deps/share/lua/5.1/?/init.lua;$prefix/?.lua;$prefix/?/init.lua;;./?.lua;/usr/local/openresty/luajit/share/luajit-2.1.0-beta3/?.lu a;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/openresty/luajit/share/lua/5.1/?.lua;/usr/local/openresty/luajit/share/lua/5.1/?/init.lua;"; lua_package_cpath "$prefix/deps/lib64/lua/5.1/?.so;$prefix/deps/lib/lua/5.1/?.so;;./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/openresty/luajit/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so;"; # Tải xuống mã lua lua_code_cache on; upstream nature_upstream { server 127.0.0.1:6699; #upstream Trang chủ hello world Tìm kiếm # Không có thông tin balancer balancer_by_lua_block { local balancer = require "ngx.balancer" local upstream = ngx.ctx.api_ctx.upstream local ok, err = balancer.set_current_peer(upstream.host, upstream.port) if not ok then ngx.log(ngx.ERR, "failed to set the current peer: ", err) return ngx.exit(ngx.ERROR) end } } init_by_lua_block { -- Không tìm thấy lb local roundrobin = require("resty.roundrobin") local nodes = {k1 = {host = '127.0.0.1', port = 6698}, k2 = {host = '127.0.0.1', port = 6699}} cục bộ ns = {} cho k, v theo cặp(nút) do -- 初始化 trọng lượng ns[k] = 1 bộ chọn cục bộ cuối = roundrobin:new(ns) -- 初始化路由 cơ số cục bộ = require("resty.radixtree") cục bộ r = radix.new({ {paths = {'/aa/d'}, siêu dữ liệu = picker}, }) -- 匹配路由 router_match = function() local p, err = r:match(ngx.var.uri, {}) if err then log.error(err) end -- 执行 roundrobin lb 选择 local k, err = p:find() nếu không k thì return nil, err end returnnodes[k] end } server { #监听端口需要修改 nghe 8699 tái sử dụng; location / { # 在access阶段匹配路由 access_by_lua_block { local upstream = router_match() if upstream then ngx.ctx.api_ctx = { upstream = upstream } else ngx.exit(404) end } proxy_http_version 1.1; proxy_pass http://nature_upstream; #转发到 upstream } } #为了大家方便理解和测试，我们引入一个hello world 服务 server { #监听端口需要修改nghe 6699; vị trí / { văn bản default_type/html; content_by_lua_block { ngx.say("HelloWorld") } } } }
                            
                          

Bắt đầu dịch vụ và kiểm tra.

                            
                              $ openresty -p ~/openresty-test -c openresty.conf #Lỗi $ curl --request GET 'http://127.0.0.1:8699/aa/d' #Lỗi    
502 Bad Gateway Xem sitemap của VNExpress
  $ curl --request GET 'http://127.0.0.1:8699/aa/d' #Lỗi HelloWorld $ curl --request GET 'http://127.0.0.1:8699/aa/d' #Lỗi    
502 Bad Gateway Xem sitemap của VNExpress
  $ curl --request GET 'http://127.0.0.1:8699/aa/d' #第四次 HelloWorld
                            
                          

Bạn có thể thấy lần lượt thất bại này và thành công khác, chứng tỏ rằng lb có hiệu quả.

Tất cả các triển khai lb được giới thiệu ở đây có thể tham khảo các ví dụ về bản chất.

Mục lục

Cuối cùng, bài viết về xây dựng apigateway để cân bằng tải kết thúc tại đây. Nếu bạn muốn biết thêm về cách xây dựng apigateway để cân bằng tải, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt qua các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .