Nhiều cơ sở dữ liệu Đồng bộ hoá - SignalR với tin nhắn của Backplane

Question

Vấn đề

Ứng dụng của tôi hoạt động như sau:

• 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

1. 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.
2. 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?
3. 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.

Answer 1

Bạn có yêu cầu về giao tiếp trong thời gian thực với các thiết bị khi họ trực tuyến. Một trong những cách hứa hẹn nhất để làm điều này là sử dụng ổ cắm web.

• Sử dụng ổ cắm web chính nó là không thực tế và do đó được phổ biến thư viện cho nó như SignalR, socket.io. Các thư viện này hấp thụ nhiều khó khăn phải đối mặt trong sản xuất và cũng trong quá trình phát triển. Các thư viện này thậm chí còn hỗ trợ chia tỷ lệ.
• Vì ngăn xếp của bạn là SignalR dựa trên mạng.
• SignalR sẽ hoạt động tốt trong hầu hết các trường hợp. Ở đây bạn không cần phải lo lắng về bảng nối đa năng trở thành nút cổ chai như được đưa ra trong trò chơi thời gian thực.

Nhưng duy trì một giải pháp thời gian thực tự lưu trữ như SignalR đi kèm với chi phí. Tỷ lệ thành công của truyền thông sẽ không đáng tin cậy cao trong kho SignalR và bạn sẽ phải thực hiện các cơ chế giám sát khác nhau và các quá trình chuyển đổi dự phòng. Phân phối theo địa lý cũng không được hỗ trợ. Vì vậy, lựa chọn tiếp theo cho hệ thống thời gian thực đáng tin cậy cao giải quyết tất cả các sự cố đề cập là dịch vụ được lưu trữ chẳng hạn như pub-nub.