Giới thiệu Apache Pulsar - Phần 1

Hiện nay, hầu hết các hệ thống lớn đều xây dựng dựa trên mô hình microservice. Các service này có thế giao tiếp với nhau theo nhiều cách, ở đây mình muốn chỉ ra hai cách phổ biến nhất

Synchronous: Phía client gửi một request và chờ nhận một response trả về từ phía người nhận dựa trên giao thức HTTP, eg: REST, SOAP...

Asynchronous: Phía client gửi một message thông qua message queue trung gian mà không cần thiết phải chờ nhận response trả về. Một message queue phổ biến nhất có thể kể tới là Apache Kafka

Đối với một số bài toán đòi hỏi một lượng request lớn, liên tục như streaming, đồng bộ các bên, giao dịch,... thì việc giao tiếp thông qua message queue tốt hơn cả. Nhưng để tìm một message queue đủ tin cậy, không bị mất dữ liệu, có khả năng chịu lỗi, dễ dàng mở rộng là điều rất quan trọng. Kafka đã làm tốt nhưng chưa đủ, khả năng mở rộng khó khăn, một số tính năng quan trọng như Geo-replication, Tired-storage,… tự bản thân không hỗ trợ và chỉ có được ở bản enterprise. Apache Pulsar sinh ra đã giải quyết được tất cả các vấn đề trên và quan trọng nó hoàn toàn miễn phí

Bài viết dưới đây sẽ đưa ra cho các bạn một cái nhìn tổng quan, chức năng hoạt động của từng thành phần, cũng như ưu và nhược điểm so với message queue phổ biến nhất hiện nay là Apache Kafka

1, Giới thiệu chung

• Apache Pulsar là một message queue được phát triển bởi Yahoo! hiện do Apache quản lý
• Apache Pulsar có độ trễ thấp, khả năng scale out dễ dàng, lưu trữ bền bỉ, hỗ trợ nhiều tính năng nổi bật như Geo-replication (Multi-datacenter), Multi-tenancy, Tired-storage,…
• Hiện nay có rất nhiều các công ty lớn trên thế giới sử dụng có thể kể tới Tencent, Yahoo!Japan, Huawei, Splunk,…

2, Kiến trúc tổng quát

Apache Pulsar gồm có ba thành phần chính:

• Broker: Nơi xử lý và load balancing toàn bộ các message đầu vào của producer, và phân các message tới các consumer. Ngoài ra, Broker đọc các metadata có trong Zookeeper để điều phối các task và lưu trữ các message vào các đối tượng Bookeeper tương ứng,…
• Bookeeper: Tương ứng với một bookie là nơi lưu trữ các messages
• Zookeeper: Lưu trữ metadata của Bookeeper, Broker, Topics,…

Một Apache Pulsar cluster có thể bao gồm một hoặc nhiều Brokers, Bookkeepers (Bookies)

Bản thân Apache Pulsar cluster chạy 2 instances khác nhau của Zookeeper:

• Local Zookeeper: Lưu trữ metadata Broker, Bookeepers,… của bản thân cụm đó
• Configuration Store: Lưu trữ metadata các Clusters, Tenants,…. Sử dụng cho mục đích Geo-replication

3, Messages và Storage

Topic

Cũng giống như các hệ thống message queue, Topic như một địa chỉ để trao đổi các message giữa Producer và Consumer

Một Topic được gán cho một Broker

Topic url có dạng:

• {persistent|non-persistent}://tenant/namespace/topic
• Persistent, toàn bộ messages sẽ được lưu xuống ổ đĩa, non-persistent thì messages sẽ không lưu xuống ổ đĩa
• Tenant: Cần thiết cho việc cross data giữa các clusters, và tính năng Multi-tenancy trong pulsar
• Namespace: Nhóm các Topics
• Topic: đơn vị nhỏ nhất

Việc phân rã thành các tầng giúp quản lý các Topic tốt hơn, tùy từng mức sẽ có các quyền hạn khác nhau

Partition Topic

Một Topic thông thường sẽ được gán cho một Broker, việc này sẽ làm giới hạn thông lượng tối đa của Topic, Partition Topic tức Topic sẽ đó sẽ được gán cho nhiều Broker khác nhau, giúp nâng cao thông lượng

Nhìn vào hình trên có thể thấy, Topic1 có 5 partitions trải qua 3 Brokers, có 2 Consumers đang consume messages từ Topic1, Routing mode sẽ xác định những messages nào sẽ được gán vào Broker nào, và Subscription mode sẽ xác định messages đi vào Consumers nào

Các kiểu Supscription mode gồm có:

• Exclusive
• Failover
• Shared
• Key_shared

Broker

• Thành phần duy nhất tương tác với client (Producers và Consumers), cung cấp các service cho client kết nối tới Broker
• Broker là stateless, không lưu trữ data
• Khi một Broker lỗi, toàn bộ thông tin Topic được gán sang Broker khác, không phải copy data, messages được gửi nhận bình thường

Bookie

• Toàn bộ log message được lưu trữ vào các Segments (Được hiểu là Ledger theo khái niêm Apache Bookkeeper)
• Một Segment mới được tạo ra sau khi Segment cũ vượt quá kích thước hoặc thời gian lưu trong file config
• Các Segment sẽ được balancing trên toàn bộ các Bookies trong cluster, do đó không bị giới hạn bởi kích thước lưu trữ của một Bookie nào trong cluster

Segment-centric Storage

Nhờ vào kiến trúc 3 thành phần trên mà Apache Pulsar có những điểm lợi sau:

• Một Topic không bị bó buộc lưu trữ ở một phân vùng nào, do toàn bộ data đều được balancing trên toàn bộ Bookies có trong cluster
• Khả năng Scale out độc lập giữa các thành phần
• Khả năng Scale out không cần phải rebalacing lại data, xét trên 3 trường hợp: Broker lỗi, Bookie lỗi, Khả năng scale out

Trường hợp 1: Broker lỗi

• Broker là stateless, không lưu trữ data nên không cần copy data
• Dịch chuyển một phần Topic sang Broker khác, nhận request bình thường

Trường hợp 2: Bookie lỗi

• Cơ chế “sửa” lại Segment bị lỗi dựa trên các bookie khác
• Toàn bộ quá trình “sửa” đều được thực hiện ngầm bên dưới
• Broker tiếp tục nhận các request ghi bình thường

Trường hợp 3: Khả năng scale out

• Data không cần phải copy
• Tự động rebalancing data khi có data mới, những data mới sẽ ưu tiên các Bookie mới được thêm vào Cluster

So sánh với Apache Kafka

Mặc dù cả hai Apache Kafka và Apache Pulsar giống nhau về mặt khái niệm như client cùng tương tác thông qua topic, nhưng Apache Kafka tổ chức lưu trữ dựa trên Partition-centric, còn Apache Pulsar dựa trên Segment-centric

Nhờ vào kiến trúc kết nối lỏng nên Apache Pulsar có khả năng scale tốt hơn hẳn so với Apache Kafka, ngoài ra cũng dễ dàng cài đặt các tính năng như Geo-replication, Multi-tenancy,...

Mặc dù vậy, Apache Pulsar vẫn còn một số điểm yếu như chi phí tài nguyên, cộng đồng chưa đủ lớn, ít tool hỗ trợ monitoring,...

4, Kết luận

Apache Pulsar là một message queue rất tốt với khả năng scale không giới hạn, hỗ trợ rất nhiều tính năng quan trọng như Geo-replication, Multi-tenancy, Tired-storage,...

Hy vọng bài viết trên giúp mọi người có cái nhìn tổng quát hơn về thành phần, kiến trúc, cũng như những điểm mạnh, điểm yếu của nó so với Apache Kafka.

Phần 2 mình sẽ đi vào chi tiết cấu trúc bên trong của bookie, tunning một số config giúp tăng khả năng chịu lỗi, cũng như giới thiệu các tính năng có trong Apache Pulsar

(Còn tiếp...)