Chia sẻ Phiên giữa các phiên bản tomcat (không sử dụng Các phiên cố định)

Question

Tôi sẽ có 3 máy chủ Tomcat và Bộ cân bằng tải gửi các yêu cầu mà không sử dụng 'sticky sessions'.

Tôi muốn chia sẻ dữ liệu của các phiên giữa các máy chủ và tôi đang nghĩ đến việc kiên trì chúng trong DB. Tôi muốn sử dụng memcached làm lớp ở phía trước DB của mình để phân phối các yêu cầu nhanh hơn và đến don't put my db under heavy load.

Tôi đang suy nghĩ trong việc cung cấp Trình quản lý tomcat tùy chỉnh sử dụng memcached trước khi nhận/lưu trữ dữ liệu phiên cho DB vào lúc này tôi không thấy cách minh bạch (có nghĩa là tôi sẽ phải quản lý nó một lần nữa trong trường hợp tôi chuyển sang một máy chủ ứng dụng khác).

Đây có phải là giải pháp tốt hay bạn có thấy cách tiếp cận tốt hơn không?

Answer 1

Chúng tôi làm một điều tương tự trong ứng dụng của chúng tôi (Weblogic, nhưng điều đó không quan trọng), nơi chúng tôi có khóa phiên duy nhất được lưu trữ dưới dạng cookie trong trình duyệt. Chìa khóa đó sau đó sẽ được sử dụng tại mỗi yêu cầu để khôi phục dữ liệu phiên có liên quan từ cơ sở dữ liệu.

Sử dụng nguyên tắc này, chúng tôi luôn có thể chuyển sang máy chủ khác bằng trình cân bằng tải mà không cần người dùng nhận thấy bất kỳ điều gì. Ngoài ra, chúng tôi hầu như không lưu trữ bất kỳ thứ gì có liên quan trong phiên của người dùng và làm việc với nhiều trường ẩn trong trình duyệt (trình cân bằng tải hỗ trợ mã hóa URL và bảo vệ hình thức giá trị, vì vậy chúng tôi đang ở bên an toàn ...) .

Answer 2

Tôi nghĩ rằng Terracotta Web Sessions là những gì bạn muốn.

Answer 3

Lưu trữ trạng thái phiên của bạn bên ngoài máy chủ ứng dụng (Tomcat trong trường hợp của bạn), là cấu hình rất phổ biến và được đề xuất cho các trang web có quy mô lớn. Điều này thường được thực hiện để theo đuổi kiểu kiến ​​trúc có tên là Shared Nothing.

Bạn có thể lưu trữ trạng thái của mình ở nhiều nơi khác nhau: db, memcached, bộ nhớ đệm được sao chép thương mại, v.v. Tất cả đều hoạt động với các hỗn hợp thương mại khác nhau. Cá nhân, tôi đã thành công lớn với memcached. Memcached cực nhanh và ổn định.

Nói chung, tôi chọn đơn giản và sử dụng N máy chủ memcache trong đó N> 1, nói 2. Khi người dùng đăng nhập, máy chủ ứng dụng lật đồng xu để quyết định máy chủ lưu trữ trạng thái người dùng. Cookie được gửi tới trình duyệt bao gồm thông tin để biết máy chủ memcache nào sẽ định tuyến từ đó trở đi. Các yêu cầu tiếp theo từ trạng thái tìm nạp trình duyệt từ máy chủ memcache thích hợp trên mỗi yêu cầu. Nếu máy chủ memcache không thành công, người dùng sẽ phải đăng nhập lại khi máy chủ ứng dụng chọn lại máy chủ mới nhưng điều đó cực kỳ hiếm.

Answer 4

Các phiên có sẵn trong cơ sở dữ liệu giới hạn khả năng mở rộng của bạn. Nếu khả năng mở rộng không quan trọng đối với bạn điều này (db + memcached) là một cách tiếp cận hợp lệ.

Một điều bạn cần lưu ý khi sử dụng các mảng không dính là các yêu cầu đồng thời: khi bạn có, ví dụ: ajax-yêu cầu (thực hiện song song/đồng thời) chúng sẽ được phục vụ bởi các loại tomcats khác nhau (do không dính) và do đó truy cập vào phiên đồng thời. Miễn là bạn có yêu cầu đồng thời có thể sửa đổi phiên bạn cần phải thực hiện một số loại khóa đồng bộ hóa/phiên.

Có lẽ điều này khiến bạn quan tâm: Tôi đã tạo ra memcached-session-manager với mục tiêu cả hiệu suất tối ưu và khả năng mở rộng không giới hạn. Nó có thể hoạt động với bất kỳ chương trình phụ trợ tương thích memcached (ví dụ như memcachedb, membase, vv hoặc chỉ memcached). Mặc dù ban đầu nó được tạo cho phương pháp tiếp cận phiên dính, đã có một branch for nonsticky-sessions hiện tại và một số sample app cho biết cách hoạt động của nó như thế nào. Ngay bây giờ có một số thread on the mailing list on further improvements for nonsticky-sessions (xử lý các yêu cầu đồng thời và ngăn ngừa một điểm lỗi).