Kiến trúc xử lý sự kiện bất đông bộ Cape

Cape là một framework được phát triển bởi team Dropbox giúp xử lý sự kiện bất đồng bộ thời gian thực một cách chính xác ở quy mô lớn. Một vài con số về framework này:

  • Đang chạy trên hàng ngày servers trên khắp các lục địa
  • Đăng ký hơn 30 nhóm sự kiện với tần suất 30.000 event/s
  • Xử lý 150.000 jobs/s
  • Hơn 95% sự kiện được xử lý dưới 1 giây

Vậy framework này được thiết kế như thế nào?

Subject level isolation

Cô lập các cấp độ chủ đề là rào cản lớn nhất trong việc sử dụng các công nghệ thông thường như Queue.

Có thể nói là sẽ không thực tế trong việc tạo ra mỗi 1 queue cho 1 chủ đề vì như vậy chúng ta sẽ phải tạo ra hàng tỉ hàng đợi. Vấn đề của việc sử dụng Kafka là hàng đợi là việc Kafka yêu cầu mỗi consumer xác nhận sự kiện sau khi nó xử lý xong. Việc này phát sinh vấn để tắc nghẽn lớn vì nó ngăn cản việc xử lý của các sự kiện khác cho đến khi sự kiện ở đầu của hàng đợi được xác nhận xong.

Độ trễ này là không chấp nhận được vì có hàng nghìn subject tạo ra sự kiện mỗi giây và lamda runtimes có thể thay đổi từ mili giây đến 10 phút.

Độ trể này có thể khắc phục bằng cách tách riêng việc độ và việc xác nhận sự kiện. Giải pháp này cho phép consumer tiếp tục đọc sự kiện mới trong khi vẫn có thể xử lý xác nhận chúng một cách bất đồng bộ.

Tuy nhiên, nếu bất kỳ sự kiện nào không được xử lý, bên phía consumer sẽ phải tua lại và xử lý một lượng lớn các sự kiện có thể xảy ra của các đối tượng khác. Việc tua lại này là cần thiết để đảm bảo thành công “ít nhất một lần” cho mọi sự kiện. Về cơ bản, thất bại trong một đối tượng có thể gây ra quá trình xử lý trùng lặp và độ trễ tăng thêm cho các đối tượng khác, điều này phá vỡ sự cô lập giữa các đối tượng.

SQS cung cấp một giải pháp tốt hơn cho loại cô lập này. Khi một sự kiện đang được tiêu thụ, nó sẽ bị ẩn đi đối với những consumer khác, cho đến khi đạt đến thời hạn quy định. Sau khi quá trình xử lý thành công kết thúc, consumer xác nhận nó và sự kiện được xóa khỏi hàng đợi. Điều này cho phép người tiêu dùng tiếp tục tìm nạp các sự kiện mới mà không phải lo lắng về việc tua lại khi bị lỗi.

Tuy nhiên với SQS có một vấn đề khi việc sắp xếp thứ tự xử lý được quan tâm. Mặc dù hoạt động theo cơ chế FIFO cho phép việc sắp xếp quá trình tiêu thụ consumption, nó lại gặp vấn đề về giới hạn throughput. Nếu không, vấn đề là trước khi xử lý một sự kiện, không có cách nào để người tiêu dùng biết liệu các sự kiện trước đó có được xử lý thành công hay không. Nếu không biết điều đó, sẽ không thể đảm bảo việc xử lý theo thứ tư.

Phức tạp hóa vấn đề hơn, một bản ghi nhớ (record) cho biết consumer nào có quyền xử lý riêng biệt chủ đề sẽ được tạo ra (để đảm bảo các sự kiện của cùng một chủ thể được xử lý theo thứ tự). Loại ghi nhớ (keepbooking) gây ra khó khăn trong vì duy trì dẫn đến chung ta cần phải xây dựng thêm dịch vụ cho việc ghi nhớ này.

Độ tin cậy của event source

Cuối cùng chung ta quay lại thiết lập ban đầu: event phải được phát hành theo 1 cách đủ tin cậy. Thông thường, việc tạo event nằm trong chức năng quan trọng của Dropbox (sync file hoặc đăng ký user). Trong hệ thống phân tán, các lỗi xảy ra mọi lúc. Khi có lỗi, lựa chọn hợp lý là từ bỏ để tránh ảnh hưởng đến tính khả dụng của dịch vụ quan trọng. Sự kiện không được công bố.

Tham khảo:

https://dropbox.tech/infrastructure/cape-technical-deep-dive

Leave a Reply

Your email address will not be published. Required fields are marked *