Làm thế nào là độ dính phiên đạt được trên nhiều máy chủ web?


23

StackOverflow / ServerFault có bao nhiêu máy chủ web?

Nếu câu trả lời là 'nhiều hơn một', thì nó có đạt được Độ dính phiên trong khi bỏ phiếu DNS không?


Không thực sự, nhưng nếu nó được đặt cụm từ khác nhau, nó có thể tạo ra một câu hỏi thú vị.

Bạn nên viết lại câu hỏi. Thay đổi tiêu đề thành "Độ dính phiên đạt được trên nhiều máy chủ web như thế nào?" hoặc một cái gì đó tương tự ...
William Brendel

bạn có thể giúp tôi chỉ cho tôi cụm từ đúng không?

1
Giả định rằng có nhiều máy chủ ngụ ý các phiên dính - vốn là một điều kinh tởm - làm tôi đau đớn.
womble

Câu trả lời:


42

Các trang web lớn có thể được "cân bằng tải" trên nhiều máy. Trong nhiều thiết lập cân bằng tải, người dùng có thể nhấn bất kỳ máy phụ trợ nào trong một phiên. Do đó, một số phương thức tồn tại để cho phép nhiều máy chia sẻ phiên người dùng.

Phương pháp được chọn sẽ phụ thuộc vào kiểu cân bằng tải được sử dụng, cũng như tính khả dụng / dung lượng của bộ lưu trữ phụ trợ:

Thông tin phiên chỉ được lưu trữ trong cookie : Thông tin phiên (không chỉ là định danh phiên) được lưu trữ trong cookie của người dùng. Ví dụ: cookie của người dùng có thể chứa nội dung trong giỏ hàng của họ. Để ngăn người dùng giả mạo dữ liệu phiên, có thể cung cấp HMAC cùng với cookie. Phương pháp này có lẽ ít phù hợp nhất cho hầu hết các ứng dụng:

  • Không cần lưu trữ phụ trợ
  • Người dùng không cần phải đánh cùng một máy mỗi lần, vì vậy có thể sử dụng cân bằng tải DNS
  • Không có độ trễ liên quan đến việc truy xuất thông tin phiên từ máy cơ sở dữ liệu (vì nó được cung cấp với yêu cầu HTTP). Hữu ích nếu trang web của bạn được cân bằng tải bởi các máy trên các lục địa khác nhau.
  • Lượng dữ liệu có thể được lưu trữ trong phiên bị giới hạn (theo giới hạn kích thước cookie 4K)
  • Mã hóa phải được sử dụng nếu người dùng không thể xem nội dung của phiên
  • HMAC (hoặc tương tự) phải được sử dụng để ngăn người dùng giả mạo dữ liệu phiên
  • Vì dữ liệu phiên không được lưu trữ phía máy chủ, nên các nhà phát triển khó gỡ lỗi hơn

Bộ cân bằng tải luôn hướng người dùng đến cùng một máy : Nhiều bộ cân bằng tải có thể đặt cookie phiên của riêng họ, cho biết người dùng nào đang thực hiện yêu cầu và chuyển chúng đến máy đó trong tương lai. Bởi vì người dùng luôn được hướng đến cùng một máy, không cần chia sẻ phiên giữa nhiều máy. Điều này có thể tốt trong một số tình huống:

  • Việc xử lý phiên của ứng dụng hiện tại có thể không cần phải thay đổi để trở nên nhận biết nhiều máy
  • Không có hệ thống cơ sở dữ liệu dùng chung (hoặc tương tự) được yêu cầu để lưu trữ các phiên, có thể làm tăng độ tin cậy, nhưng với chi phí phức tạp
  • Một máy phụ trợ đi xuống sẽ gỡ xuống bất kỳ phiên người dùng nào bắt đầu với nó, với nó.
  • Đưa máy ra khỏi dịch vụ là khó khăn hơn. Người dùng có phiên trên máy bị gỡ xuống để bảo trì nên được phép hoàn thành nhiệm vụ trước khi tắt máy. Để hỗ trợ điều này, bộ cân bằng tải web có thể có một tính năng để "thoát" các yêu cầu đến một máy phụ trợ nhất định.

Cơ sở dữ liệu phụ trợ được chia sẻ hoặc lưu trữ khóa / giá trị : Thông tin phiên được lưu trữ trong cơ sở dữ liệu phụ trợ, tất cả các máy chủ web có quyền truy cập để truy vấn và cập nhật. Trình duyệt của người dùng lưu trữ cookie chứa mã định danh (như ID phiên), chỉ vào thông tin phiên. Đây có lẽ là phương pháp sạch nhất trong ba:

  • Người dùng không bao giờ cần phải tiếp xúc với thông tin phiên được lưu trữ.
  • Người dùng không cần phải đánh cùng một máy mỗi lần, vì vậy có thể sử dụng cân bằng tải DNS
  • Một nhược điểm là nút cổ chai có thể được đặt trên bất kỳ hệ thống lưu trữ phụ trợ nào được sử dụng.
  • Thông tin phiên có thể được hết hạn và sao lưu nhất quán.

Nhìn chung, hầu hết các ứng dụng web động thực hiện một số truy vấn cơ sở dữ liệu hoặc yêu cầu lưu trữ khóa / giá trị, vì vậy cơ sở dữ liệu hoặc kho lưu trữ khóa / giá trị là vị trí lưu trữ logic của dữ liệu phiên.


2
+1 Câu trả lời khá toàn diện và tiết kiệm cho tôi viết nó. :) Theo lưu trữ db, cơ sở dữ liệu quan hệ có lẽ là điều sai. Một cái gì đó giống như một trong những dĩa memcached dai dẳng là tốt hơn. memcachedb có thể phù hợp. Bạn cũng bỏ lỡ sao chép thông tin phiên giữa các máy chủ. Đây không phải là phương pháp tốt nhất, nhưng những thứ như tomcat làm điều đó, rất đáng để ghi lại.
David Pashley

Phương pháp nào được Google, Twitter hoặc Facebook sử dụng?
Dannyboy

1
Không chắc chắn về Google, Twitter hay Facebook, nhưng Redis rất phù hợp cho một cửa hàng phiên. Về cơ bản, David Pashley "memcached" đã được đề xuất vào năm 2009, khi Redis còn phôi thai.
Ben R

4

Nếu câu hỏi của bạn là làm thế nào để duy trì các phiên trên nhiều máy chủ web mặt trước, thì câu trả lời thường là sử dụng cơ sở dữ liệu tập trung. Thay vì dựa vào các phiên bản máy chủ web để theo dõi các tệp phiên trên hệ thống tệp cục bộ, bạn sẽ viết id phiên và dữ liệu vào DB trung tâm và thay vào đó, tất cả các máy chủ web sẽ truy xuất dữ liệu từ đó.


+1 để đề cập đến cơ sở dữ liệu centalized. Chỉ cần mở rộng / đơn giản hóa ý tưởng đó một chút. Nếu bạn đặt cookie trên PC của người dùng với một cái gì đó độc đáo như ID người dùng toàn cầu, thì bạn có thể lưu GUID đó trong cơ sở dữ liệu. Việc máy khách kết nối với máy chủ nào sẽ không thành vấn đề, miễn là họ có GUID / cookie, bạn sẽ có thể tra cứu chúng dựa trên cơ sở dữ liệu và theo dõi phiên phù hợp.
KPWINC

2
Lưu trữ các phiên trong cơ sở dữ liệu quan hệ luôn là một ý tưởng tồi. Bạn không nên sử dụng cơ sở dữ liệu để lưu trữ dữ liệu nhất thời.
David Pashley

2

Sử dụng nemcached dường như là một giải pháp tốt không được đề cập bởi @David Pashley

Điều này có nghĩa là có một phiên bản memcached từ xa được chia sẻ bởi tất cả các máy chủ và sử dụng phần mở rộng PECL memcache cung cấp trình xử lý phiên riêng của nó.

Nó chỉ yêu cầu thay đổi hai tham số trong cấu hình php!

Dưới đây là một hướng dẫn tốt http://www.dotdeb.org/2008/08/25/storing-your-php-simes-USE-memcached/


Nhưng có nhiều trung tâm dữ liệu là gì?
Dannyboy

0

IIRC, trong DotNetRocks # 440, họ cho biết một thời kỳ máy chủ. Không biết nếu đó vẫn là trường hợp.

Chỉnh sửa: Thật ra đó là Hanselminutes # 134 . Lấy làm tiếc.


0

Bạn có thể đặt cookie.

Bạn có thể tính toán một hàm băm của IP từ xa (tại các máy chủ từ xa được đánh số lẻ, đơn giản nhất của nó đến máy chủ A, các máy chủ được đánh số chẵn đi đến máy chủ B).

Có vẻ như bạn cũng có thể thực hiện điều đó thông qua một số giá trị nằm trong hệ thống nguồn nếu bạn đang sử dụng đường hầm ssl.

Thông thường, mỗi cơ chế trên yêu cầu máy chủ "proxy ngược" hoặc bộ cân bằng tải nào đó. Bộ cân bằng tải đó chấp nhận lưu lượng và sau đó hướng nó đến bất kỳ máy chủ nào ban đầu có phiên, dựa trên một trong các tiêu chí trên.

Tuy nhiên, tôi không chắc ý của bạn về "bỏ phiếu DNS"


0

a) Bạn có thể lưu trữ thông tin phiên trong cookie người dùng. Xem cookie cứng không trạng thái, không lưu trữ dữ liệu nào ở phía máy chủ, nhưng vẫn giữ trạng thái phiên http://www.cl.cam.ac.uk/~sjm217/ con / prot Protocol08cookies.pdf . b) Bạn có thể thay đổi lưu trữ phụ trợ phiên thành cơ sở dữ liệu hoặc memcached. Để loại bỏ một điểm lỗi duy nhất, bạn có thể đặt sao chép cơ sở dữ liệu hoặc nhiều nút memcached. Lưu ý, memcached được khuyến nghị trong các thiết lập như vậy trong đó việc mất trạng thái người dùng trong phiên không phải là lỗi lớn và không làm cho anh ta rất không hài lòng. Đối với các trường hợp trong đó bảo tồn nhà nước là quan trọng, sử dụng cơ sở dữ liệu. Cả PHP, Django và Rails đều cho phép nhà phát triển viết phần phụ trợ phiên tùy chỉnh.

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.