Các phiên dính và không dính


255

Tôi muốn biết sự khác biệt giữa các phiên dính và không dính. Những gì tôi hiểu sau khi đọc từ internet:

Chú ý : chỉ có đối tượng phiên duy nhất sẽ ở đó.

Phiên không dính : đối tượng phiên cho mỗi nút máy chủ

Câu trả lời:


612

Khi trang web của bạn chỉ được phục vụ bởi một máy chủ web, đối với mỗi cặp máy khách-máy chủ, một đối tượng phiên được tạo và lưu lại trong bộ nhớ của máy chủ web. Tất cả các yêu cầu từ máy khách đến máy chủ web này và cập nhật đối tượng phiên này. Nếu một số dữ liệu cần được lưu trữ trong đối tượng phiên trong khoảng thời gian tương tác, thì nó được lưu trữ trong đối tượng phiên này và ở đó miễn là phiên tồn tại.

Tuy nhiên, nếu trang web của bạn được phục vụ bởi nhiều máy chủ web nằm phía sau bộ cân bằng tải, bộ cân bằng tải sẽ quyết định máy chủ web thực tế (vật lý) mà mỗi yêu cầu sẽ đi đến. Ví dụ: nếu có 3 máy chủ web A, B và C phía sau bộ cân bằng tải, có thể www.mywebsite.com/index.jsp được phục vụ từ máy chủ A, www.mywebsite.com/login.jsp được phục vụ từ máy chủ B và www.mywebsite.com/accoutdetails.php được phục vụ từ máy chủ C.

Bây giờ, nếu các yêu cầu được phục vụ từ (vật lý) 3 máy chủ khác nhau, mỗi máy chủ đã tạo một đối tượng phiên cho bạn và vì các đối tượng phiên này nằm trên ba hộp độc lập, không có cách nào trực tiếp để biết có gì trong đối tượng phiên của những thứ còn lại. Để đồng bộ hóa giữa các phiên máy chủ này, bạn có thể phải ghi / đọc dữ liệu phiên thành một lớp chung cho tất cả - như DB. Bây giờ viết và đọc dữ liệu đến / từ một db cho trường hợp sử dụng này có thể không phải là một ý tưởng tốt. Bây giờ, đây là vai trò của phiên dính .

Nếu bộ cân bằng tải được hướng dẫn sử dụng các phiên dính, tất cả các tương tác của bạn sẽ xảy ra với cùng một máy chủ vật lý, ngay cả khi các máy chủ khác có mặt. Do đó, đối tượng phiên của bạn sẽ giống nhau trong toàn bộ tương tác của bạn với trang web này.

Tóm lại, trong trường hợp Phiên dính, tất cả các yêu cầu của bạn sẽ được chuyển đến cùng một máy chủ web vật lý trong khi trong trường hợp trình cân bằng tải không dính có thể chọn bất kỳ máy chủ web nào để phục vụ yêu cầu của bạn.

Ví dụ: bạn có thể đọc về Bộ cân bằng tải đàn hồi của Amazon và các phiên dính tại đây: http://aws.typepad.com/aws/2010/04/new-elastic-load-balANCE-feature-sticky-simes.html


4
@ TJ- điều gì sẽ xảy ra nếu một nút không khả dụng?
gstackoverflow 8/11/2015

20
Trong hầu hết các trường hợp, phiên sẽ bị mất. Trong trường hợp AWS ESB Nếu một trường hợp không thành công hoặc trở nên không lành mạnh, bộ cân bằng tải sẽ dừng yêu cầu định tuyến đến trường hợp đó, thay vào đó chọn một phiên bản lành mạnh mới dựa trên thuật toán cân bằng tải hiện có. Bộ cân bằng tải xử lý phiên như bây giờ "bị mắc kẹt" với trường hợp khỏe mạnh mới và tiếp tục định tuyến các yêu cầu đến trường hợp đó ngay cả khi trường hợp thất bại quay trở lại.
TJ- 9/11/2015

8
Theo những thông tin nào thì LoadBalancer tạo ra một phiên HTTP dính? Đặc biệt trên các kết nối HTTPS vấn đề này trở nên thú vị. Bạn có cung cấp LB với khóa riêng của máy chủ web để có thể ngắt kết nối SSL và tìm nạp phiên HTTP không? Hay LB chỉ đơn giản là sử dụng địa chỉ IP của máy khách? Trong trường hợp này, còn máy chủ proxy nơi nhiều khách hàng sử dụng cùng một địa chỉ IP thì sao? Hoặc thậm chí tệ hơn, các máy khách di động, nơi địa chỉ IP thay đổi thường xuyên? Hoặc thậm chí có một kỹ thuật tốt hơn cho điều đó? Cảm ơn
g000ze

6
Vâng, bạn hoàn toàn chính xác. Để sử dụng tiêu đề "x-chuyển tiếp-cho" hoặc cookie dính trong ngữ cảnh này, Chấm dứt SSL cần được sử dụng và do đó, yêu cầu cần được giải mã tại LB.
TJ-

4
@ g000ze Khi xử lý các ứng dụng không được phục vụ trực tiếp trên internet, tôi tin rằng chỉ nên bật TLS trên máy chủ proxy ngoài cùng. (Một bộ cân bằng tải có thể được coi là một loại máy chủ proxy đặc biệt, có thể chuyển yêu cầu tới bất kỳ máy chủ nào.) Lưu lượng giữa bộ cân bằng tải và các máy chủ khác sẽ xảy ra trên mạng cục bộ, được bảo mật và do đó thường không cần thiết phải mã hóa nó hoặc nếu cần mã hóa, chứng chỉ tự ký có thể đủ (vì proxy có thể được cấu hình để tin tưởng nó).
jpmc26

106

Tôi đã trả lời với một số chi tiết ở đây: https://stackoverflow.com/a/11045462/592477

Hoặc bạn có thể đọc nó ở đó ==>

Khi bạn sử dụng cân bằng tải, điều đó có nghĩa là bạn có một vài trường hợp tomcat và bạn cần chia tải.

  • Nếu bạn đang sử dụng sao chép phiên mà không có phiên dính: Hãy tưởng tượng bạn chỉ có một người dùng sử dụng ứng dụng web của mình và bạn có 3 trường hợp tomcat. Người dùng này gửi một số yêu cầu đến ứng dụng của bạn, sau đó trình cân bằng tải sẽ gửi một số yêu cầu này đến phiên bản tomcat đầu tiên và gửi một số yêu cầu khác đến phiên bản thứ hai và khác cho yêu cầu thứ ba.
  • Nếu bạn đang sử dụng phiên dính mà không cần sao chép:Hãy tưởng tượng bạn chỉ có một người dùng sử dụng ứng dụng web của mình và bạn có 3 trường hợp tomcat. Người dùng này gửi một số yêu cầu đến ứng dụng của bạn, sau đó loadbalancer sẽ gửi yêu cầu người dùng đầu tiên đến một trong ba trường hợp tomcat và tất cả các yêu cầu khác được gửi bởi người dùng này trong phiên của anh ta sẽ được gửi đến cùng phiên bản tomcat. Trong các yêu cầu này, nếu bạn tắt hoặc khởi động lại phiên bản tomcat này (phiên bản tomcat được sử dụng), bộ cân bằng sẽ gửi các yêu cầu còn lại đến một phiên bản tomcat khác vẫn đang chạy, NHƯNG khi bạn không sử dụng sao chép phiên, phiên bản tomcat nhận được các yêu cầu còn lại không có bản sao của phiên người dùng, sau đó đối với tomcat này, người dùng bắt đầu một phiên: người dùng mất phiên và bị ngắt kết nối khỏi ứng dụng web mặc dù ứng dụng web vẫn đang chạy.
  • Nếu bạn đang sử dụng phiên dính với sao chép phiên:Hãy tưởng tượng bạn chỉ có một người dùng sử dụng ứng dụng web của mình và bạn có 3 trường hợp tomcat. Người dùng này gửi một số yêu cầu đến ứng dụng của bạn, sau đó loadbalancer sẽ gửi yêu cầu người dùng đầu tiên đến một trong ba trường hợp tomcat và tất cả các yêu cầu khác được gửi bởi người dùng này trong phiên của anh ta sẽ được gửi đến cùng phiên bản tomcat. Trong các yêu cầu này, nếu bạn tắt hoặc khởi động lại phiên bản tomcat này (phiên bản tomcat được sử dụng), bộ cân bằng sẽ gửi các yêu cầu còn lại đến một phiên bản tomcat khác vẫn đang chạy, khi bạn sử dụng sao chép phiên, thì tomcat cá thể nhận các yêu cầu còn lại có một bản sao của phiên người dùng sau đó người dùng tiếp tục phiên của mình: người dùng tiếp tục duyệt ứng dụng web của bạn mà không bị ngắt kết nối, việc tắt phiên bản tomcat không ảnh hưởng đến điều hướng người dùng.

8
Hmm .. đọc điều này tôi tự hỏi: nó sẽ có ý nghĩa khi có một lựa chọn thứ tư: Không dính với sao chép phiên? Hoặc đặt khác nhau: lợi thế của việc có một phiên dính là gì nếu một phiên bản sao chép phiên này sang các phiên bản khác nhau? Ý tôi là, nếu bạn đang sao chép các phiên trên các phiên bản, bạn cũng có thể chuyển tiếp yêu cầu đến bất kỳ máy chủ nào, phải không? Tôi đang thiếu gì?
dingalapadum

@dingalapadum bạn nói đúng, về mặt lý thuyết bạn có thể sao chép phiên mà không cần phiên dính. Nhưng trong trường hợp một cụm lớn, điều đó không tốt cho hiệu suất mạng. Sau đó, có một số chiến lược trong việc sử dụng sao chép phiên với phiên dính như thế này trong tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) là đặt một phiên dính và chỉ một bản sao (một nút ở đây được gọi là trình quản lý sao lưu giữ tất cả các bản sao phiên của nút).
Nico

Sau đó, phiên dính cho phép bạn chỉ có một bản sao phiên, tốt nhất trong cụm lớn.
Nico

2
À tôi hiểu rồi - Nếu tôi hiểu chính xác, ý bạn là sao chép tất cả các phiên trên toàn bộ cụm sẽ tràn vào bên trong cụm - tôi thấy vấn đề. Ồ, và bây giờ nhìn kỹ hơn câu trả lời của bạn, tôi mới thấy, đây thực sự là trường hợp đầu tiên bạn mô tả ... 'duh me' ..
dingalapadum

@dingalapadum câu hỏi của bạn được chào đón, nó cho phép cải thiện câu trả lời
Nico
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.