Không có sách trắng và nó giống như 200 dòng mã nên không quá nhiều để nuốt.
Trong SignalR, mỗi bản tin đi qua một thứ gọi là bus bản tin. Khi bạn muốn mở rộng quy mô trên các nút (hoặc quy trình hoặc miền ứng dụng), việc triển khai bus này cần có khả năng giao tiếp với từng phiên bản ứng dụng của bạn. Để làm điều này, bạn có thể sử dụng RedisMessageBus. Redis có cơ chế phụ của quán rượu cũng như khả năng lưu trữ các cặp giá trị chính và chúng tôi chỉ sử dụng cơ chế cũ cho SignalR.
OffTopic:Điều này RẤT quan trọng! SignalR KHÔNG phải là tin nhắn đáng tin cậy, nó là một kết nối trừu tượng. Chúng tôi có thể đệm các tin nhắn cho longpolling nhưng bạn ** không thể * dựa vào các tin nhắn ở đó mãi mãi. Nếu bạn có những tin nhắn quan trọng cần lưu lại, hãy tiếp tục gửi chúng.
Mỗi máy chủ web kết nối với một (hoặc nhiều trong triển khai mới) redis sự kiện để gửi tin nhắn giữa chúng. Khi một tin nhắn đến cho một hoặc nhiều máy khách, nó sẽ được gửi đến bảng nối đa năng (redis) và nó sẽ đến trên tất cả các máy chủ web. Mỗi máy chủ web nhận thông báo từ redis và lưu trữ nó trong bộ nhớ cache cục bộ. Bộ đệm cục bộ này là nơi phục vụ các máy khách SignalR (trình duyệt, v.v.).
Một phần quan trọng của thiết kế scale out là con trỏ. Con trỏ biểu thị vị trí của một khách hàng cụ thể trong một luồng thông báo vô hạn. Khi máy khách kết nối lại sau khi ngắt kết nối hoặc kết nối chờ đợi sẽ quay trở lại sau khi nhận được thông báo, nó yêu cầu xe buýt lấy cho tôi mọi thứ kể từ một số giá trị con trỏ. Con trỏ được xác định bởi triển khai bus thông báo và chúng tôi đã chuẩn hóa điều này trong các nguồn mới nhất (chưa được phát hành tại thời điểm viết bài nhưng tôi sẽ không đi vào chi tiết ở đây). Con trỏ trong quá trình triển khai redis hiện tại chỉ là một số tăng dần, không có gì quá phức tạp.
Hy vọng rằng điều đó cung cấp một số ý tưởng về cách nó hoạt động.
