Các trung tâm sự kiện có nên được chia nhỏ trên loại thông báo không?

Question

Tôi đang xem xét sử dụng Trung tâm sự kiện Azure cho một dự án mà tôi hiện đang làm việc. Chúng tôi đang sử dụng hàng đợi dịch vụ xe buýt cho các lệnh ngày hôm nay và ở đây chúng tôi đang sử dụng một hàng đợi cho mỗi messagetype.

Sẽ có ý nghĩa khi có một số Trung tâm sự kiện hoặc tốt hơn nên sử dụng một trung tâm cho một số loại thông báo?

Answer 1

Đây là câu hỏi đầy sự cân bằng và thực hiện phán đoán về những hệ thống bạn mong muốn xây dựng hiện tại và trong tương lai và cách chúng có thể sử dụng các loại sự kiện khác nhau.

Dưới đây là phần trích dẫn từ some of the guidance Jay Kreps đã đưa ra các hệ thống thiết kế trên Apache Kafka áp dụng tốt cho Trung tâm tổ chức sự kiện (ngoại trừ trường hợp giới hạn áp dụng thời gian lưu giữ ngắn và giới hạn số lượng nhóm người tiêu dùng)).

Hãy bắt đầu với dữ liệu sự kiện thuần túy — các hoạt động diễn ra bên trong công ty. Trong một công ty web, đây có thể là nhấp chuột, hiển thị và nhiều hành động của người dùng khác nhau. FedEx có thể có giao hàng trọn gói, nhận gói hàng, vị trí lái xe, thông báo, chuyển khoản và như vậy.

Các loại sự kiện này có thể được biểu diễn bằng một luồng logic duy nhất cho mỗi loại hành động. Để đơn giản, tôi khuyên bạn nên đặt tên lược đồ Avro và chủ đề giống nhau, ví dụ: PageViewEvent. Nếu sự kiện có khóa chính tự nhiên, bạn có thể sử dụng nó để phân vùng dữ liệu trong Kafka, nếu không máy khách Kafka sẽ tự động tải dữ liệu cân bằng cho bạn.

...

Chúng tôi đã thử nghiệm vào các thời điểm khác nhau với việc trộn nhiều sự kiện trong một chủ đề và thấy điều này thường dẫn đến sự phức tạp quá mức. Thay vào đó, hãy cung cấp cho mỗi sự kiện đó là chủ đề riêng và người tiêu dùng luôn có thể đăng ký nhiều chủ đề như vậy để nhận nguồn cấp dữ liệu hỗn hợp khi họ muốn.

Tôi thường đồng ý với lời khuyên này (và bạn nên đọc toàn bộ bài đăng trên blog đó nếu bạn đang thiết kế hệ thống trên Trung tâm sự kiện/Kafka/Kinesis). Người đăng ký cần phải bỏ qua các thư họ không quan tâm không chỉ gây phiền nhiễu, nó sẽ trở thành vấn đề sau này nếu một trong các loại sự kiện bắt đầu thống trị luồng kết hợp.

Nhưng việc có nhiều luồng và kết hợp chúng lại với nhau sẽ có chi phí và chúng cần phải được cân nhắc khi đưa ra quyết định. Tôi đã liệt kê một số ý nghĩ đó.

1. Bạn bị mất trật tự giữa các sự kiện thuộc loại khác nhau từ cùng một nguồn trừ khi bạn cố gắng thêm lại.

2. Nếu bạn muốn cam kết cùng nhau với các chủ đề khác nhau thì bạn cần quản lý chúng.

3. Nếu bạn đang phân vùng sự kiện phát trên một khóa chính được chia sẻ giữa chủ đề và muốn phân vùng trong từng chủ đề đi cùng nhau, bạn không thể sử dụng các ứng dụng khách cao cấp như EventProcessorHost vì phân vùng có thể tự động kết thúc với quy trình.

4. Một người tiêu dùng có một luồng trên mỗi phân đoạn kết thúc nhân số lượng chủ đề cần thiết cho số chủ đề. Có lẽ không phải là một vấn đề, trừ khi bạn có cấu trúc đắt tiền mà không thể được chia sẻ.

Trong triển khai của riêng mình, chúng tôi sử dụng các trung tâm sự kiện khác nhau cho các loại sự kiện khác nhau. Điều này đơn giản chỉ vì tôi hy vọng sẽ thêm các thành phần mới chỉ quan tâm đến một số loại sự kiện nhất định. Tôi hy vọng điều này sẽ giúp, và tồi tệ nhất tôi đã nói với bạn để đi xem hướng dẫn cho Kafka vì nguyên tắc là như nhau và nó được xung quanh lâu hơn.