2013-02-02 25 views

Trả lời

6

Có thể có nhiều công dụng cho thuật ngữ này, nhưng tôi luôn thấy nó được sử dụng trong trường hợp nhiều kết nối TCP đang được thực hiện trong một khoảng thời gian rất ngắn, gây ra các vấn đề về hiệu suất trên máy khách và máy chủ .

Điều này thường xảy ra khi mã máy khách được viết tự động kết nối trên một lỗi TCP thuộc bất kỳ loại nào. Nếu lỗi này xảy ra là lỗi kết nối trước khi kết nối được thực hiện (hoặc rất sớm trong trao đổi giao thức) thì máy khách có thể đi vào vòng lặp bận rộn liên tục tạo kết nối. Điều này có thể gây ra các vấn đề về hiệu suất ở phía máy khách - trước hết là có một quá trình trong một vòng lặp rất bận rộn, thu hút các chu trình CPU, và thứ hai là mỗi lần kết nối tiêu thụ một số cổng phía máy khách - nếu điều này đủ nhanh phần mềm có thể quấn quanh khi họ nhấn số cổng tối đa (như một cổng chỉ là một số 16-bit, điều này chắc chắn là không thể).

Trong khi viết mã mạnh mẽ là một mục tiêu xứng đáng, phương pháp "thử lại tự động" đơn giản này hơi quá ngây thơ. Bạn có thể thấy các vấn đề tương tự trong các ngữ cảnh khác - ví dụ: một quá trình cha mẹ liên tục khởi động lại một tiến trình con mà ngay lập tức bị treo. Một cơ chế phổ biến để tránh nó là một số loại tăng trở lại. Vì vậy, khi kết nối đầu tiên không thành công, bạn sẽ kết nối lại ngay lập tức. Nếu không thành công trong vòng một thời gian ngắn (ví dụ: 30 giây) thì bạn sẽ đợi, giả sử, 2 giây trước khi kết nối lại. Nếu không thành công trong vòng 30 giây, bạn sẽ đợi 4 giây, v.v. Đọc the Wikipedia article on exponential backoff (hoặc this blog post có thể phù hợp hơn cho ứng dụng này) để biết thêm thông tin cơ bản về kỹ thuật này. Cách tiếp cận này có lợi thế là nó không áp đảo khách hàng hoặc máy chủ, nhưng nó cũng có nghĩa là khách hàng vẫn có thể phục hồi mà không cần sự can thiệp thủ công (ví dụ, đặc biệt quan trọng đối với phần mềm trên máy chủ không cần giám sát). cụm).

Trong trường hợp thời gian khôi phục rất quan trọng, việc giới hạn tốc độ tạo kết nối TCP đơn giản cũng khá khả thi - có thể không quá 1 mỗi giây hoặc thứ gì đó. Tuy nhiên, nếu có nhiều máy khách trên mỗi máy chủ, cách tiếp cận đơn giản hơn này vẫn có thể khiến máy chủ bị tràn ngập bởi tải chấp nhận rồi đóng một tỷ lệ kết nối cao. Một điều cần lưu ý nếu bạn định sử dụng backoff theo cấp số nhân - tôi đề nghị áp dụng thời gian chờ tối đa hoặc bạn có thể thấy rằng lỗi kéo dài khiến khách hàng mất quá nhiều thời gian để phục hồi sau khi kết thúc máy chủ bắt đầu chấp nhận lại kết nối. Tôi sẽ đề nghị một cái gì đó như 5 phút như là một tối đa hợp lý trong hầu hết trường hợp, nhưng tất nhiên nó phụ thuộc vào ứng dụng.

+0

Làm cho tinh thần - điều này chắc chắn có thể là một vấn đề đối với dịch vụ với phía máy khách không thể truy cập (các) máy chủ khác. Cảm ơn câu trả lời của bạn! – eman

Các vấn đề liên quan