Vấn đề
Ứng dụng của tôi hoạt động như sau:Nhiều cơ sở dữ liệu Đồng bộ hoá - SignalR với tin nhắn của Backplane
- Nhiều (< 20) khách hàng thiết bị (Android) đang chạy tại một địa điểm duy nhất.
- Hàng nghìn vị trí tồn tại (do đó hàng chục hoặc hàng trăm nghìn thiết bị khách hàng tồn tại).
- Ứng dụng khách cổng thông tin web cũng tồn tại hoạt động đồng bộ với dữ liệu của từng vị trí và ứng dụng khách của thiết bị.
- Dữ liệu mới được tạo trên thiết bị được đăng lên máy chủ (đám mây) thông qua API REST (ASP.net WebAPI).
Cho đến nay ứng dụng này là một ứng dụng khá chuẩn với ứng dụng khách trên thiết bị di động và ứng dụng cổng web. Tuy nhiên, do yêu cầu trên mỗi thiết bị khách hàng nằm ngoài tầm kiểm soát của tôi (thiết bị khách hàng cần phải hoạt động ở chế độ ngoại tuyến, giảm độ trễ mạng, vv), mỗi thiết bị khách không sử dụng cơ sở dữ liệu máy chủ ghi lại. Mỗi máy khách thiết bị có cơ sở dữ liệu cục bộ (SQLite) riêng của nó vẫn đồng bộ với tất cả dữ liệu cho vị trí của nó. Ví dụ: khi tôi thực hiện thay đổi dữ liệu trên máy khách thiết bị A, thay đổi đó cần phải được truyền cho khách hàng thiết bị B và ứng dụng khách cổng web C.
- Máy khách cổng web đọc trực tiếp từ cơ sở dữ liệu máy chủ vì nó không cần chức năng ngoại tuyến.
Như bạn có thể thấy, vấn đề ở đây là chúng ta cần một cách để giữ cho tất cả các cơ sở dữ liệu khách hàng thiết bị đồng bộ với nhau trong thời gian thực. Sự chậm trễ trong dữ liệu đang được đồng bộ giữa hai thiết bị khách hàng được mong đợi và được coi là không sao.
đề xuất giải pháp
giải pháp đề xuất của tôi là như sau:
- Khi một thiết bị khách hàng mới đến trực tuyến ban đầu, nó nhận được một bãi chứa dữ liệu cho những gì nó đã bỏ lỡ kể từ lần cuối cùng nó đã online từ máy chủ thông qua REST API.
- Mỗi mục dữ liệu mới được đăng/cập nhật/xóa khỏi thiết bị khách thông qua REST API được truyền đến cơ sở dữ liệu máy chủ. Cơ sở dữ liệu máy chủ chứa tất cả dữ liệu cho tất cả các vị trí và nên được coi là nguồn bản ghi vĩnh viễn.
- Cổng web hoạt động trực tiếp với cơ sở dữ liệu máy chủ vì nó không có yêu cầu loại ngoại tuyến.
- Kết nối từ mỗi thiết bị khách được thiết lập thành dịch vụ luồng đồng bộ hóa dữ liệu qua SignalR.
- Dịch vụ công nhân đang "điều chỉnh" cơ sở dữ liệu máy chủ cho các hoạt động Tạo/Cập nhật/Xóa mới. Khi một hoạt động CUD được phát hiện, một thông điệp được gửi đến một hàng đợi/đăng ký Bus Service Azure (thông qua chủ đề fan-out) cho mỗi cá thể dịch vụ đồng bộ hóa dữ liệu. Điều này cho phép mở rộng quy mô ngang của dịch vụ đồng bộ dữ liệu SignalR (với bảng nối đa năng dịch vụ Azure) vì hàng nghìn kết nối máy khách thiết bị sẽ tồn tại.
- Dịch vụ đồng bộ dữ liệu đọc từ hàng đợi/đăng ký tin nhắn và đẩy thông điệp đồng bộ (chứa tất cả dữ liệu cần thiết cho đồng bộ) cho tất cả các thiết bị khách được kết nối (cho vị trí liên quan đến dữ liệu) qua SignalR.
Sơ đồ dưới đây minh họa giải pháp này:
- khối lớn mô tả máy chủ (hình vuông màu xám là HTTP máy chủ web có thể được thu nhỏ theo chiều ngang)
- Mũi tên miêu tả sự chỉ đạo của dữ liệu chảy qua ứng dụng.
Câu hỏi
- là SignalR công nghệ phù hợp với vấn đề này/giải pháp? Ban đầu giải pháp của tôi liên quan đến mỗi thiết bị khách hàng thiết lập hàng đợi/đăng ký dịch vụ Azure của chính nó mà đã thu thập thông điệp từ nhân viên điều chỉnh cơ sở dữ liệu (sông đồng bộ). Vấn đề với giải pháp đó là tôi sẽ đẩy rất nhiều tin nhắn lãng phí cho các khách hàng thiết bị ngoại tuyến có thể không quay lại trực tuyến trong một thời gian rất dài, nếu có. Bằng cách bán lại dữ liệu delta khi một thiết bị khách truy cập trực tuyến ban đầu và truyền dữ liệu qua SignalR sau đó tôi có thể giải quyết vấn đề này.
- Tôi đã không sử dụng SignalR rộng rãi trong một môi trường sản xuất trước đây, vì vậy tôi là một chút mới với nó. Những vấn đề/thách thức nào tôi có thể mong đợi để trải nghiệm với nó cho giải pháp này?
- article sau đây cho biết "Có một số tình huống mà bảng nối đa năng có thể trở thành nút cổ chai. Đây là một số trường hợp SignalR điển hình: Thời gian thực tần số cao (ví dụ: trò chơi trong thời gian thực): Không được khuyến nghị sử dụng bảng nối đa năng. ". Giải pháp này có thuộc loại này không? Vấn đề gì có thể backplane của Azure Service Bus nhắn tin giới thiệu? Làm thế nào khác tôi sẽ mở rộng giải pháp này nếu không theo cách này?
Ý kiến chung và đề xuất của bạn cho giải pháp này cũng được hoan nghênh và đánh giá cao.
Tôi nghĩ điều này có thể hữu ích, vui lòng xem https://msdn.microsoft.com/en-us/sync/bb980926.aspx –