SignalR mở rộng với Azure EventHub

Question

Tôi đang tìm giải pháp mở rộng tần số cao cho SignalR. Tôi tự hỏi nếu tôi có thể làm điều đó với Azure EventHub. Nếu tôi sử dụng EventHub làm bảng nối đa năng cho các tin nhắn SignalR, liệu nó có trở thành nút cổ chai cho tôi không?

Tôi đã kiểm tra this trang nhưng không có gì về EventHub vì nó khá mới.

Answer 1

Tôi không thể nói chi tiết cụ thể của SignalR; tuy nhiên, bạn có thể sử dụng nguyên tắc EventHubs cho một bảng nối đa năng, nhưng bạn cần phải nhận thức được những hạn chế.

Mô hình tỷ lệ bảng nối đa năng của SignalR giả định rằng tất cả các máy chủ sẽ có quyền truy cập vào tất cả các thư và xử lý tất cả chúng một cách có chủ ý. Điều này cung cấp một giới hạn khá rõ ràng về những gì một bảng nối đa năng có thể thực hiện trên phần cứng hàng hóa hoặc trong đám mây. Trong một đám mây điển hình, bạn có thể duy trì thông lượng dữ liệu 100MB/s (số vòng tròn đẹp cho 1 Gb/s nic), phần trên của phần cứng hàng hóa (và máy HPC của Azure) 1000MB/s (10 Gbit/giây nic).

Vì vậy, câu hỏi đặt ra là Azure EventHub có thể đưa bạn đến giới hạn kiến ​​trúc này về thông lượng không?

Câu trả lời cho điều đó đơn giản là có. 100 hoặc 1000 phân vùng sẽ cung cấp cho bạn đủ thông lượng ghi và đủ khả năng đọc cho 2 máy chủ.

Câu hỏi tiếp theo là, nếu bạn chỉ cần 100MB/giây đọc trên bảng nối đa năng trên mỗi máy chủ có bao nhiêu máy chủ có thể đọc dữ liệu (tức là nếu bạn đang phát 100MB/giây mã cổ phiếu nơi kích thước dữ liệu không tăng với số lượng máy chủ).

Câu trả lời ở đây là, bao nhiêu tùy thích nhưng có một số thủ thuật.

Sự kiệnXếp hạng tỷ lệ bằng cách phân đoạn luồng dữ liệu. Mỗi phân vùng mỗi phân vùng sẽ có thông lượng đọc tối đa là 2MB/s được chia sẻ trên tất cả các độc giả. Tuy nhiên, bạn chỉ có thể nhân số lượng phân vùng để bù đắp cho việc chia nhỏ (thêm hơn 32 yêu cầu nói chuyện với Microsoft). Giả thiết thiết kế của EventHubs (như Kafka và Kinesis) là tiêu thụ sẽ được phân chia trên các máy do đó tránh giới hạn backplane được thảo luận trước đó. Người tiêu dùng đang làm việc cùng nhau để đọc luồng là Nhóm Người tiêu dùng (Azure dường như yêu cầu một CG có tên ngay cả đối với người đọc trực tiếp), trong mô hình bảng nối đa năng này không có nhóm người tiêu dùng hợp lý, vì vậy câu hỏi là cách đọc dữ liệu.

Giải pháp đơn giản nhất có thể là sử dụng Trình xử lý sự kiện tự động điều chỉnh mức cao Host với mỗi máy chủ là Nhóm người tiêu dùng riêng của mình với một tên cố định. Với chỉ một máy chủ trong mỗi nhóm người tiêu dùng, mỗi máy chủ sẽ nhận được tất cả các phân vùng (500 cho 10 máy chủ để đạt 100MB/giây, tức là $ 11k/tháng + $ 0,028 cho mỗi triệu sự kiện).

Cách tiếp cận này có một giới hạn chính: bạn bị giới hạn ở 20 consumer groups per event hub. Vì vậy, bạn có thể chuỗi các trung tâm tổ chức sự kiện với nhau hoặc tạo một cây với cách tiếp cận này để nhận các số tùy ý.

Tùy chọn khác là sử dụng các ứng dụng khách trực tiếp kết nối với các phân vùng cụ thể. A single partition in a consumer group can have 5 readers do đó làm giảm sự cần thiết cho chuỗi trung tâm theo hệ số 5 do đó cắt giảm chi phí cho mỗi sự kiện theo hệ số 5 (không làm giảm yêu cầu đơn vị thông lượng).

Tóm lại, nó không nên trở thành cổ chai trước khi bất kỳ bảng nối đa năng nào trở thành nút cổ chai. Nhưng đừng xây dựng thứ gì đó trên bảng nối đa năng nếu bạn mong đợi nó vượt quá lưu lượng 100MB/giây.

Tôi không nói về độ trễ, bạn sẽ cần tự mình kiểm tra, nhưng rất có thể bạn không thực hiện HFT trên đám mây và có lý do trò chơi thời gian thực thường trong các trường hợp.