Ứng dụng Stateful vs non-stateful [đã đóng]

Tôi đã được học về các ứng dụng trạng thái so với phi trạng thái, nhưng tôi vẫn hơi bối rối về chủ đề này.

Ví dụ: giả sử tôi có một ứng dụng chạy trên Node nơi người dùng được chỉ định vào các phòng ngẫu nhiên ngay khi họ kết nối qua socket.io. Đây là những căn phòng gồm 4 người và không tồn tại dưới bất kỳ hình thức nào, nhưng chúng được lưu trữ trong một biến toàn cục dưới dạng bản đồ băm. Tôi không sử dụng db (quá nhiều truy vấn) cũng không phải redis (nó quá đắt).

Đây có phải là một ví dụ về một ứng dụng trạng thái hay không?

Trong ngữ cảnh của các ứng dụng web, chúng tôi gọi máy chủ là trạng thái nếu nó duy trì trạng thái nhất thời trong bộ nhớ , thay vì lưu trữ bất kỳ dữ liệu nào bên ngoài (ví dụ: trong cơ sở dữ liệu).

Các ứng dụng có trạng thái có một số vấn đề, ví dụ:

• bạn không thể có nhiều máy chủ chạy mà không ghim phiên vào một máy chủ cụ thể
• trạng thái bị mất khi khởi động lại máy chủ

Do đó, cách tốt nhất là tránh trạng thái phía máy chủ (một lần nữa: trừ khi nó được lưu trữ bên ngoài trong cơ sở dữ liệu).

Các phụ trợ ứng dụng web thường không cần lưu trữ bất kỳ trạng thái phiên nào vì chúng có thể sử dụng các nguyên tắc REST: trạng thái được chuyển giữa máy khách và máy chủ. Trạng thái này được thể hiện bằng URL, cookie, nội dung HTTP, v.v. Điều này là cần thiết bởi vì HTTP là một giao thức không trạng thái (về mặt ngữ nghĩa, không nhất thiết phải nằm trong nền tảng kỹ thuật của nó).

Với các ổ cắm web, các nguyên tắc này bị hỏng một chút vì máy khách đang duy trì phiên / kết nối dài hạn với máy chủ - và kết nối đó liên quan đến trạng thái. Điều này là không thể tránh khỏi, nhưng bạn có kiểm soát được hay không và mức độ sử dụng websockets sẽ thỏa hiệp với thiết kế phụ trợ không trạng thái.

• Hoàn toàn ổn khi duy trì cấu trúc dữ liệu trong bộ nhớ kiểm soát kết nối nào được đăng ký với sự kiện nào.

• Sẽ là có vấn đề nếu cấu trúc dữ liệu trong bộ nhớ đó là nguồn của sự thật.

  • Nếu đăng ký được cho là thoáng qua, mọi thứ đều ổn.
  • Nếu bạn muốn thiết lập lại các mục đăng ký tương tự khi khách hàng kết nối lại, bạn cần lưu trữ trạng thái này ở một nơi khác. Ví dụ: phía máy chủ trong cơ sở dữ liệu hoặc phía máy khách thông qua cookie hoặc LocalStorage.

Nói chung, duy trì trạng thái máy chủ nội bộ là tốt khi một trong những điều sau đây được áp dụng

• nhà nước được lưu trữ bên ngoài
• trạng thái không được chia sẻ giữa các yêu cầu
• nhà nước chỉ là việc mua lại một nguồn tài nguyên đắt tiền có thể được sử dụng lại, ví dụ như các kết nối cơ sở dữ liệu
• trạng thái là bộ đệm cho một số nguồn dữ liệu có thẩm quyền, mặc dù điều này dẫn đến các vấn đề khó khăn như mất hiệu lực bộ đệm và tính nhất quán cuối cùng

Nếu bạn đang lưu trữ trạng thái trên máy chủ cần thiết để xử lý yêu cầu đến từ máy khách, thì máy chủ sẽ ở trạng thái. Nói một cách khác, nó nói rằng nó lưu trữ và cần truy cập để xử lý các yêu cầu từ khách hàng. Vì vậy, hashmap của bạn là trạng thái để máy chủ của bạn có trạng thái.

Bây giờ, có rất ít ứng dụng web thực sự làm được những điều phong phú mà không có trạng thái nào cả. Rốt cuộc, nếu bạn sẽ có một người dùng đăng nhập và sau đó xử lý các yêu cầu theo lệnh của khách hàng đã đăng nhập, thì theo định nghĩa, bạn đang lưu trữ trạng thái trên máy chủ liên quan đến một khách hàng cụ thể và máy chủ có trạng thái , ngay cả khi chỉ cho các thông tin đăng nhập.

Vì vậy, tôi sẽ không quá bận tâm về việc không có trạng thái nào trên máy chủ. Vấn đề là máy chủ có bao nhiêu trạng thái, mức độ đắt đỏ (về xử lý, lưu trữ, v.v.) để lưu trữ và truy cập trạng thái này và bạn vẫn có thể mở rộng quy mô ứng dụng của mình theo trạng thái này. Và, bất cứ nơi nào thực tế giữ trạng thái trong máy khách, không phải trên máy chủ. Như một ví dụ tầm thường, giả sử bạn có một ứng dụng khách có nút "trang tiếp theo". Bạn có thể triển khai "trang tiếp theo" với trạng thái phía máy khách của trạng thái phía máy chủ.

Nếu bạn có trạng thái phía máy chủ cho trang hiện tại của máy khách, bạn có thể gửi lệnh đến máy chủ mà bạn muốn xem trang "tiếp theo". Máy chủ sẽ xem xét trạng thái của nó cho máy khách đó, tăng trang và sau đó trả lại dữ liệu cho trang tiếp theo.

Hoặc, bạn có thể lưu trữ trang hiện tại trên máy khách. Khi khách hàng muốn trang tiếp theo, nó sẽ lấy số trang hiện tại của nó, tăng nó lên một và đưa ra yêu cầu chung cho số trang cụ thể mà nó muốn xem tiếp theo.

Bạn nghĩ quy mô nào trong số những triển khai này tốt hơn? Cách nào đơn giản hơn để thực hiện khi người dùng mở tab thứ hai đang xem một trang khác? Đó là đơn giản hơn để quy mô theo chiều ngang. Câu trả lời cho tất cả những câu hỏi đó là câu trả lời không lưu trữ trang hiện tại trên máy chủ, nhưng giữ nó trong máy khách và chỉ thực hiện các yêu cầu chung cho trang N đến máy chủ. Giữ phía máy khách trạng thái đó giúp dễ dàng chia tỷ lệ riêng lẻ và theo chiều ngang và hỗ trợ nhiều chế độ xem cho cùng một khách hàng.