Đang cố gắng mở rộng quy mô Apache Kafka? Cân nhắc sử dụng Apache Pulsar

Ngày nay, ngay cả những ứng dụng di động và web cơ bản nhất cũng tiêu tốn rất nhiều dữ liệu. Chìa khóa để trao đổi và hành động trên dữ liệu này là một hệ thống nhắn tin được hỗ trợ bởi kiến trúc hướng sự kiện.

Một hệ thống hướng sự kiện cho phép các giải pháp nhắn tin và xử lý có thể mở rộng và không đồng bộ. Các hệ thống không đồng bộ có thể xử lý nhiều yêu cầu hơn, vì mỗi yêu cầu được xử lý ở chế độ nền.

Khi một yêu cầu được gửi tới máy chủ, nó sẽ được thêm vào hàng đợi, nơi bộ xử lý sẽ đọc nó. Điều này cho phép các tổ chức xây dựng hệ thống chấp nhận hàng trăm nghìn — hoặc thậm chí hàng triệu — yêu cầu mỗi giây trên quy mô lớn bằng cách xử lý các yêu cầu trong một cụm riêng biệt.

Ngành này đã sản xuất một số hệ thống môi giới thông báo và các nền tảng xuất bản-đăng ký theo chủ đề (pub-sub) tuân theo định dạng hướng đến sự kiện và thông báo này. Apache Kafka và Apache Pulsar là hai ví dụ được sử dụng rộng rãi về các hệ thống phát và gửi thư phân tán .

Kafka và Pulsar đều được xây dựng trên mẫu pub-sub mà bạn có thể sử dụng để mở rộng quy mô gửi tin nhắn tới hàng nghìn khách hàng được kết nối. Cả hai đều cung cấp mô hình lưu trữ liên tục để đảm bảo thư không bị mất và cả hai đều sử dụng phân vùng để lưu trữ và xử lý thư.

Mặc dù Kafka và Pulsar giống nhau về nhiều mặt, nhưng chúng có một số khác biệt đáng chú ý về khả năng — đặc biệt là khi quản lý lượng dữ liệu lớn, tạo ứng dụng thời gian thực và phát triển trên quy mô lớn.

Kafka mang lại nhiều lợi ích, nhưng sự hỗ trợ của Pulsar đối với khả năng mở rộng và tăng trưởng là không thể so sánh được. Và tại một thời điểm nhất định trong quá trình phát triển, lựa chọn tối ưu là không còn cố gắng tối ưu hóa Kafka nữa mà thay vào đó là chia tay với nó. Ở đây, chúng tôi sẽ so sánh sự khác biệt giữa Kafka và Pulsar, chứng minh bước tiếp theo hợp lý cho khả năng mở rộng khi sử dụng Kafka là chuyển sang Pulsar.

Những thách thức với Ứng dụng Apache Kafka

Kafka là thực tế cho các mẫu pub-sub phân tán trong kiến trúc phần mềm. Một tổ chức sử dụng Kafka có khả năng xử lý hàng nghìn tin nhắn và truyền tin nhắn tới nhiều người tiêu dùng cùng một lúc.

Kafka có một số lợi ích , nhưng nó cũng có những hạn chế nhất định khi cố gắng mở rộng quy mô. Hãy cùng khám phá một số thách thức mà bạn sẽ gặp phải khi cố gắng mở rộng các ứng dụng được xây dựng bằng Apache Kafka.

Giới hạn lưu trữ

Kiến trúc của Kafka tạo ra thách thức đầu tiên mà bạn sẽ gặp phải khi mở rộng ứng dụng của mình trong Kafka: lưu trữ.

Stateful brokers là lý do đầu tiên khiến một tổ chức gặp khó khăn trong việc mở rộng quy mô. Dữ liệu trong Kafka được lưu trữ trong nút đầu , trong khi các phân vùng dữ liệu được lưu trữ trên đĩa cục bộ. Dữ liệu được gắn với các nút và các nhà môi giới trong Kafka có trạng thái. Điều này có nghĩa là khi nút dẫn đầu đã đạt đến dung lượng lưu trữ tối đa, cụm không thể chấp nhận thêm thông báo trừ khi dung lượng lưu trữ cơ sở hạ tầng được tăng lên. Đây là một thách thức bởi vì trong một môi trường ngày càng phát triển, một cụm sẽ yêu cầu nhiều lần nâng cấp.

Một cách để vượt qua thách thức này là mua một cụm lưu trữ lớn, rất tốn kém.

Ngoài ra, dựa trên kiến trúc này, khi nền tảng đã đạt đến giới hạn bộ nhớ hoặc bộ nhớ tối đa, nền tảng không thể chấp nhận thư mới đến. Điều này có thể dẫn đến một tổn thất lớn cho các ứng dụng kinh doanh quan trọng. Kiến trúc của Kafka được thiết kế để chấp nhận và phát đi rất nhiều thông điệp. Lưu trữ dữ liệu dài hạn không phải là một ưu tiên. Do đó, việc mở rộng quy mô ứng dụng Kafka là rất khó khăn vì nó không thể cung cấp dung lượng lưu trữ mà bạn cần — ít nhất là không phải nếu không có mức giá quá đắt.

Rắc rối với Xử lý tin nhắn

Quản lý Kafka là một thách thức vì nó không bao gồm các tính năng cần thiết để giám sát hoạt động, xử lý tin nhắn và duy trì dữ liệu.

Kafka tỏa sáng cho các hệ thống phát tin nhắn không đầu, nơi bạn không cần thay đổi tin nhắn trước khi gửi. Tuy nhiên, giả sử bạn cần xử lý một tin nhắn trước khi chuyển tiếp nó đến người tiêu dùng; điều này đòi hỏi sự phụ thuộc vào các nền tảng bổ sung, điều này khiến việc xử lý tin nhắn với Kafka trở nên khó khăn và phức tạp hơn.

Hơn nữa, sự tham gia của các nền tảng khác như những nền tảng được liệt kê ở trên làm tăng đáng kể độ phức tạp của hệ thống phân phối dữ liệu của bạn, vì mỗi thành phần của nền tảng phát trực tuyến đều yêu cầu bảo trì và có các giới hạn áp dụng cho toàn bộ cụm. Ngoài ra, các cụm Kafka có dữ liệu hạn chế và thông báo vẫn tồn tại khi yêu cầu dữ liệu của bạn tăng lên theo thời gian.

Thư viện máy khách phức tạp

Các doanh nghiệp chủ yếu sử dụng Kafka cho các dịch vụ phát trực tuyến được cung cấp. API phát trực tuyến được viết ở đầu quá trình gửi tin nhắn pub-sub để hỗ trợ một trường hợp kinh doanh độc đáo . Kafka Streams API là một sản phẩm độc lập cung cấp các tính năng nâng cao dành cho khách hàng doanh nghiệp. Tính năng đáng chú ý nhất của Kafka Streams, giao dịch , giúp doanh nghiệp đảm bảo tính nhất quán của đầu ra do luồng thông báo tạo ra. Vì lý do này, Kafka có hai API riêng biệt cho từng trường hợp sử dụng.

Ví dụ: thư viện Kafka Streaming cho phép các doanh nghiệp cung cấp dịch vụ gửi tin nhắn “chính xác một lần”. Việc giao hàng đảm bảo rằng cả Kafka và Pulsar đều cung cấp:

• Ít nhất một lần
• nhiều nhất một lần
• Chính xác một lần

Việc gửi “chính xác một lần” đảm bảo rằng đối với mỗi tin nhắn, sẽ có một đầu ra được liên kết, đảm bảo tin nhắn được xử lý trong trường hợp người tiêu dùng gặp sự cố. Tuy nhiên, điều này là không thể với API người tiêu dùng , cho phép các ứng dụng đọc luồng dữ liệu từ các chủ đề trong cụm Kafka, yêu cầu bạn viết hầu hết các tính năng trong nền tảng. Điều này gây khó khăn cho việc sử dụng một thư viện máy khách duy nhất cho tất cả các tính năng bạn cần cho doanh nghiệp của mình, điều này không bền vững khi bạn làm việc trên quy mô lớn.

Nhập Pulsar

Đối với mỗi giới hạn Kafka được nêu ở trên, Pulsar có một giải pháp. Các phần sau đây phác thảo một số lợi ích của Pulsar.

Lưu trữ dữ liệu liên tục

Pulsar cung cấp các tính năng truyền phát và xuất bản tin nhắn mà Kafka thực hiện, nhưng thêm khả năng duy trì dữ liệu trong thời gian dài hơn.

Pulsar cung cấp khả năng lưu trữ dữ liệu bền bỉ bằng Apache Bookkeeper. Bookkeeper duy trì dữ liệu và giúp giảm tải dữ liệu tồn đọng bên ngoài cụm. Bạn có thể sử dụng các phương tiện lưu trữ dữ liệu khác như AWS S3 để lưu trữ dữ liệu và mở rộng quy mô vượt quá giới hạn của ổ đĩa cục bộ, nghĩa là bạn có thể dễ dàng mở rộng các ứng dụng của mình mà không cần lo lắng về dung lượng lưu trữ.

Ngoài ra, Pulsar bao gồm tính năng lưu trữ theo tầng giúp di chuyển dữ liệu giữa các tùy chọn lưu trữ nóng và lạnh; dữ liệu sau đó có thể được lưu trữ trong kho lạnh miễn là doanh nghiệp cần. Cụm không yêu cầu thay đổi liên tục về kích thước cơ sở hạ tầng cho các tùy chọn lưu trữ.

Pulsar cũng tự động di chuyển các tin nhắn cũ hơn từ Bookkeeper sang một tùy chọn lưu trữ lạnh, rẻ hơn bằng cách làm cho một phân đoạn dữ liệu trở nên bất biến. Phân đoạn không thay đổi có thể được chuyển sang bộ lưu trữ rẻ hơn, cho phép Pulsar chấp nhận lượng dữ liệu vô hạn một cách hiệu quả.

Kinh nghiệm của nhà phát triển

Từ quan điểm của nhà phát triển, Pulsar cung cấp một thư viện máy khách đơn giản, tích hợp cho tất cả các ngôn ngữ chính (Java, Python, Go và C#). Các thư viện giúp các nhà phát triển bắt đầu với nền tảng một cách nhanh chóng, đây là chìa khóa khi phát triển và phát hành ứng dụng trên quy mô lớn. Giao thức nhị phân của Pulsar mở rộng các tính năng của thư viện máy khách khi cần, làm cho thư viện phù hợp với sự phát triển. (Đây là danh sách các thư viện máy khách Pulsar có sẵn và được hỗ trợ chính thức. )

Chức năng sao xung

Pulsar Functions là một tính năng vượt trội cho phép các nhà phát triển viết mã tùy chỉnh có thể xử lý thông báo trong luồng thông báo mà không cần triển khai một hệ thống như Apache Heron, Apache Flink hoặc Apache Storm.

Các hàm Pulsar được sử dụng trong khung trình kết nối không có máy chủ Pulsar IO, giúp di chuyển dữ liệu từ và đến Pulsar dễ dàng hơn. Hệ thống sẵn dùng này cho phép Pulsar được kết nối với cơ sở dữ liệu SQL và NoSQL bên ngoài, chẳng hạn như Apache Cassandra.

Ngoài ra, quá trình xử lý thông báo này là luồng gốc, nghĩa là các thông báo được xử lý và chuyển đổi bên trong cụm trước khi chúng được gửi tới người tiêu dùng. Vì Hàm Pulsar là cơ sở hạ tầng điện toán của hệ thống nhắn tin Pulsar nên chúng hỗ trợ các mục tiêu cấp doanh nghiệp, bao gồm năng suất của nhà phát triển, khắc phục sự cố dễ dàng và đơn giản trong vận hành — những phẩm chất quan trọng đối với hiệu suất của ứng dụng và nhóm khi làm việc trên quy mô lớn.

khả năng mở rộng

Ngoài các tính năng và dịch vụ được đề cập ở trên và ảnh hưởng của chúng đối với khả năng mở rộng, Pulsar còn cung cấp nhiều tính năng khác nhau giúp nó trở thành một tùy chọn có thể mở rộng cho nhu cầu xuất bản và truyền phát thông điệp của doanh nghiệp bạn.

Tính năng sao chép địa lý của Pulsar cho phép Pulsar có khả năng mở rộng cao. Cụm sao chép dữ liệu đến nhiều địa điểm trên toàn cầu để sử dụng trong trường hợp xảy ra thảm họa khiến ứng dụng ngừng hoạt động. Bản sao được hỗ trợ đồng bộ cũng như không đồng bộ. Sao chép không đồng bộ nhanh hơn nhưng cung cấp ít đảm bảo tính nhất quán dữ liệu hơn so với sao chép đồng bộ.

Pulsar sử dụng khái niệm nhà môi giới cho mỗi chủ đề, đảm bảo rằng cùng một nhà môi giới xử lý tất cả các yêu cầu cho một chủ đề. Kiến trúc Pulsar thể hiện cách tiếp cận dựa trên trình môi giới cải thiện hiệu suất của hệ thống so với cụm Kafka.

kết thúc

Kafka và Pulsar có một số điểm tương đồng, nhưng có một số điểm khác biệt cơ bản đáng xem xét khi chọn sử dụng nền tảng nào — đặc biệt khi bạn cần khả năng mở rộng.

Kiến trúc, khả năng lưu trữ và khả năng sử dụng của Kafka đưa ra nhiều thách thức có thể cản trở khả năng phát triển của một tổ chức. Việc cố gắng mở rộng các cụm Kafka của bạn vượt quá một điểm trở nên tốn kém và thường gặp nhiều rắc rối hơn giá trị của nó. Từ cách lưu trữ dữ liệu đến cách hỗ trợ chuyển đổi thông báo, Pulsar là thế hệ tiếp theo, thách thức thống nhất đối với Kafka được xây dựng để có khả năng mở rộng.

Tìm hiểu về DataStax Astra Streaming , được xây dựng trên Apache Pulsar và được phân phối dưới dạng dịch vụ được quản lý hoàn toàn.

của Mary Grygleski. Mary là người ủng hộ nhà phát triển phát trực tuyến tại DataStax. Cô ấy tập trung vào việc phát triển vận động cộng đồng và tiếp cận cộng đồng cho Java, mã nguồn mở và công nghệ đám mây bao gồm các cấu trúc gốc trên đám mây, không có máy chủ, hướng sự kiện, vi dịch vụ và phản ứng.