Làm thế nào tốt nginx và memcached làm việc với nhau?

Chúng tôi có một ứng dụng web dựa trên Java EE chạy trên cụm máy chủ ứng dụng Glassfish . Lưu lượng đến chủ yếu sẽ là các yêu cầu RESTful cho các biểu diễn dựa trên XML của tài nguyên ứng dụng của chúng tôi, nhưng có lẽ 5% lưu lượng có thể dành cho các biểu diễn dựa trên JSON- hoặc XHTML / CSS.

Chúng tôi hiện đang điều tra các giải pháp cân bằng tải để phân phối lưu lượng truy cập đến qua các phiên bản Glassfish trong cụm. Chúng tôi cũng đang xem xét cách giảm tải cụm bằng memcached, bản đồ băm phân tán trong bộ nhớ có các khóa sẽ là tên tài nguyên REST (ví dụ: "/ user / bob", "/ group / jazzlovers") và có giá trị là các biểu diễn XML tương ứng.

Một cách tiếp cận nghe có vẻ hứa hẹn là giết cả hai con chim bằng một viên đá và sử dụng máy chủ HTTP / máy chủ ngược nginx nhẹ, nhanh . Nginx sẽ xử lý từng yêu cầu đến bằng cách trước tiên tìm URI của nó trong memcached để xem có đại diện XML chưa hết hạn ở đó không. Nếu không, nginx sẽ gửi yêu cầu tới một trong các trường hợp Glassfish. Mô-đun memcached nginx được mô tả trong bài viết ngắn này .

Ấn tượng chung của bạn với nginx và memcached được sử dụng theo cách này là gì, bạn hạnh phúc với họ như thế nào? Những tài nguyên nào bạn thấy hữu ích nhất cho việc tìm hiểu về chúng? Nếu bạn đã thử chúng và chúng không phù hợp với mục đích của bạn, tại sao không, và thay vào đó bạn đã sử dụng cái gì?

Lưu ý: đây là một câu hỏi liên quan . Trước khi tôi biết về ServerFault, tôi đã hỏi điều này trên StackOverflow .

Chỉnh sửa: Tất cả các câu trả lời ở đây cho đến nay đều khá hữu ích, mặc dù không có kinh nghiệm trực tiếp. Câu trả lời này cuối cùng đã xuất hiện trên StackOverflow và nó khá lạc quan về thiết lập nginx / memcached.

Bạn thực sự nên sử dụng một máy chủ bộ đệm trước máy chủ web của bạn. Tôi khuyên dùng Varnish-cache. Chúng tôi sử dụng nó tại nơi làm việc với trang web lớn nhất và bận rộn nhất ở scandinavia. Chúng tôi đã thay thế 13 hộp Mực được nạp nhiều bằng 1 hộp Varnish và 1 hộp dự phòng.

Tôi đã điểm chuẩn một ứng dụng đơn giản trên trang web riêng của mình và nó đã chuyển từ 9 yêu cầu một giây lên hơn 2000.

Bạn quyết định thời gian lưu giữ mọi thứ trong bộ nhớ, bạn có thể thực hiện đến hết thời gian và sau đó chỉ cần gửi yêu cầu thanh lọc http đến máy chủ bộ đệm khi dữ liệu thay đổi.

Ý kiến ​​cá nhân của tôi, từ kinh nghiệm, là nếu bạn đang sử dụng bộ cân bằng tải, bạn muốn giới hạn hoàn toàn hộp đó để tải các chức năng cân bằng. Việc bộ cân bằng tải của bạn phục vụ nội dung, thậm chí từ bộ đệm, làm suy giảm chức năng cân bằng tải trong các tình huống tải cao (nhiều kết nối sẽ hoạt động lâu hơn, giảm công suất và thông lượng tổng thể).

Tôi khuyên bạn nên để ứng dụng tự tra cứu và phục vụ nội dung được lưu trong bộ nhớ cache và để bộ cân bằng tải thực hiện công việc của mình. Phải nói rằng, nginx không hoàn hảo khi nói đến cân bằng tải - nó chỉ cung cấp một thuật toán quay vòng rất cơ bản. Tôi muốn giới thiệu haproxy thay thế. Nếu bạn cần các dịch vụ giải mã SSL ở phía trước, nginx hoạt động tốt khi ngồi trước haproxy, theo kinh nghiệm của tôi.

Tôi nghĩ bạn sẽ đi vào ngõ cụt trong trường hợp bạn sẽ cần những thứ như cân bằng tải, tính sẵn sàng cao và vv

Ngoài ra, hãy xem xét tình huống như vậy: khi người dùng được xác thực trang trông khác nhau, với các tính năng bổ sung có sẵn và được cá nhân hóa cho mỗi người dùng. Các URL giống nhau về tính liên kết và v.v. Trong những trường hợp như vậy, nginx sẽ không sử dụng được, vì bạn không thể phân biệt người dùng được xác thực với người không được xác thực.

Nếu bạn không cần SSL, tôi sẽ đề nghị bạn chạy Varnish. Nó đã được thiết kế như HTTP Accelerator, không phải là máy chủ web hoặc proxy. Nếu bạn cần SSL, hãy chạy nginx trên đầu dưới dạng trình tăng tốc SSL và véc ni như trình tăng tốc HTTP đơn giản, vì Varnish không thể đối phó với SSL.

Tôi nghĩ rằng sự lựa chọn máy chủ bộ đệm là ứng dụng cụ thể và bạn không thể đưa ra nhận xét chung chung về điều đó mà không phân tích sâu về ứng dụng.

sự lựa chọn của tôi là haproxy. Proxy đảo ngược rất nhỏ và rất nhanh, nhưng không phải là proxy proxy! Tôi sử dụng cho hệ thống bộ đệm của mình "Squid Web Proxy"

CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
                                          -> WEB II /lighttpd/
                                          -> WEB III /lighttpd/

Công việc này hoàn hảo cho hệ thống web của tôi