Thông báo trực tiếp là nơi Websockets phát triển mạnh và mang lại lợi thế to lớn so với AJAX.
Như bạn biết, điều này đã được thảo luận trước cả hai khi tranh luận về vai trò của AJAX (tuyệt vời cho CRUD, không quá nhiều khi bỏ phiếu) và khi so sánh Hiệu suất websocket so với hiệu suất AJAX (Websockets luôn nhanh hơn khi có liên quan đến các bản cập nhật trực tiếp).
Có ... bạn có thể tiết kiệm tài nguyên và cải thiện hiệu suất (cũng như các vấn đề về bảo trì mã trong tương lai) bằng cách thêm on_update "móc" vào điểm truy cập cơ sở dữ liệu.
Ý tưởng rất đơn giản:bất cứ khi nào một lệnh gọi hàm cập nhật cơ sở dữ liệu MySQL, yêu cầu cập nhật cũng được gửi đến một lệnh gọi lại. Cuộc gọi lại đó chịu trách nhiệm xuất bản bản cập nhật lên đúng kênh.
Bằng cách này, bạn không thăm dò cơ sở dữ liệu MySQL.
Một số cơ sở dữ liệu cung cấp lệnh gọi lại cập nhật và những cơ sở dữ liệu khác thì không. Tôi nghĩ MySQL thì có. Tuy nhiên, tôi tránh các lệnh gọi lại được liên kết cơ sở dữ liệu này vì chúng là cơ sở dữ liệu cụ thể. Tốt hơn (IMHO) nên thêm lệnh gọi lại vào điểm truy cập cơ sở dữ liệu trong ứng dụng, vì vậy việc thay thế cơ sở dữ liệu không ảnh hưởng đến cơ sở mã.
Tôi không nghĩ AJAX là một cách tiếp cận tốt.
HTTP / 2 giúp giảm thiểu các thiếu sót của AJAX, nhưng nó không giải quyết được tất cả chúng.
Tôi không biết bạn mong đợi có bao nhiêu máy khách được kết nối đồng thời, nhưng việc ép khách hàng gửi yêu cầu mỗi giây hoặc hai giây thì rất gần với một cuộc tấn công DoS tự gây ra.
Hãy xem xét điều này:nếu khách hàng gửi yêu cầu AJAX hai giây một lần, hơn 2.000 máy khách đồng thời, máy chủ của bạn sẽ cần phản hồi 1.000 req / giây - những yêu cầu này bao gồm xác thực, truy vấn cơ sở dữ liệu và tất cả những thứ đó.
Mặt khác, bằng cách sử dụng Websockets, với 2.000 máy khách được kết nối, bạn có 2.000 kết nối liên tục không làm gì cả cho đến khi có thông báo. Không cần CPU hoặc công việc, chỉ cần bộ nhớ của kết nối. Không có căng thẳng trên máy chủ cho đến khi dữ liệu thực tế được đẩy.
Vâng, chúng phức tạp hơn để thực hiện, nhưng chúng không khó như vậy khi bạn bắt đầu. Ngoài ra, có rất nhiều thư viện và công cụ trợ giúp giúp bạn gánh vác phần lớn công việc.
Các vấn đề phổ biến liên quan đến cách tiếp cận Websocket bao gồm việc xử lý tỷ lệ theo chiều ngang (thường bằng cách thêm cơ sở dữ liệu hoặc dịch vụ pub / sub, chẳng hạn như Redis), thứ tự thông báo (nên bỏ qua tốt hơn khi có thể) và các mối quan tâm về truyền dữ liệu (khi nào chúng tôi đánh dấu dữ liệu là "đã xem"? chúng tôi gửi toàn bộ dữ liệu hay chỉ một thông báo cho biết rằng dữ liệu có sẵn? chúng tôi sử dụng bao nhiêu kênh và chúng tôi phân chia đăng ký như thế nào?).
Thông thường, các câu trả lời là dành riêng cho ứng dụng và phụ thuộc vào tính năng bạn đang cố gắng hủy cuộn cũng như kích thước dự kiến của tập dữ liệu của bạn (nếu mọi câu trả lời tôi đưa ra trên SO là một kênh, thì việc duy trì sẽ không thực tế).
Dù sao thì ... Chúc may mắn!
