Tham gia Đăng nhập
Điểm:1
Philippe Hebert avatar Server

Làm cách nào để xử lý yêu cầu đang thực hiện khi áp dụng bản cập nhật cuốn chiếu?

lá cờ jp
Philippe Hebert

Đưa ra một tập hợp các máy chủ web có thể cập nhật theo đợt, chẳng hạn như thông qua các bản cập nhật theo đợt của kubernetes, nếu một yêu cầu được đưa ra cho một máy chủ web đang chờ chấm dứt như vậy trong một phần nghìn giây trước khi tín hiệu SIGTERM được phát cho máy chủ web nói trên,

  1. Máy chủ có nên báo hiệu cho máy khách rằng nó đang được SIGTERM'd và yêu cầu máy khách "thử lại" bằng cách sử dụng một địa chỉ mạng khác (hoặc giống nhau) (có thể có độ trễ) không?
  2. Nếu không, máy chủ có thể tự động chuyển hướng yêu cầu đến một nhóm/phiên bản khác của máy chủ web đã được triển khai không?
  3. Trong trường hợp cụ thể của kubernetes, yêu cầu có thể được gửi lại cho dịch vụ và thông báo cho dịch vụ để gửi lại sau khi ít nhất một trong số các nhóm đã được triển khai không?
39
0 + 0
Điểm:2
avatar Server
lá cờ jp
AlexD

Khi một nhóm đang kết thúc, nhóm sẽ có một khoảng thời gian (theo mặc định là 30 giây) để hoàn thành yêu cầu khi nhận được SIGTERM và trước khi nó được SIGKILL. Bạn có thể định cấu hình thời gian chờ lâu hơn. Ngoài ra còn có dừng trước móc được gọi trước SIGTERM được gửi đến một nhóm. Nhìn thấy Các phương pháp hay nhất của Kubernetes: chấm dứt với ân sủng bài đăng trên blog để biết chi tiết.

Ngoài ra, bạn có thể định cấu hình bộ cân bằng tải để thử lại các yêu cầu không thành công nhưng điều này chỉ hoạt động đối với các yêu cầu bình thường.

0 + 0
Philippe Hebert avatar
lá cờ jp
Philippe Hebert
Cảm ơn câu trả lời, @AlexD! Tôi biết rằng hoạt động mạng đến bị dừng tối đa `terminationGracePeriodSeconds` giây trước khi phát hành `SIGTERM`, theo mặc định là `30s`. Điều này thực sự bao gồm hầu hết các trường hợp sử dụng vì thực sự rất hiếm khi có yêu cầu dài hơn `30s`. Nói như vậy, trong trường hợp yêu cầu dài dòng và không thể giải quyết trong khoảng thời gian đã nêu, bạn sẽ đề xuất chiến lược là gì? Bạn có thể cho rằng yêu cầu bị ràng buộc bởi một giao dịch/không đủ điều kiện khi được trả lại sớm.
0
Hồi đáp
lá cờ jp
AlexD
@PhilippeHebert nó thực sự phụ thuộc. Chi phí thất bại của yêu cầu là gì? Chúng tôi có những tùy chọn nào để thử lại yêu cầu này? Chúng tôi có thể trì hoãn yêu cầu trong bao lâu và chi phí cho việc trì hoãn hoàn thành thành công yêu cầu là bao nhiêu? Quá nhiều biến.
0
Hồi đáp
Philippe Hebert avatar
lá cờ jp
Philippe Hebert
Đó là những câu hỏi rất xác đáng; Tôi khuyên bạn nên thêm chúng như một phần trong câu trả lời của mình, bên cạnh "Yêu cầu có phải là bình thường không?". Để hoàn thiện, nếu việc xử lý các yêu cầu này có thể được phân loại theo một số cách tiếp cận, thì tôi cũng khuyên bạn nên mô tả các cách tiếp cận này.
0
Hồi đáp
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.