- vừa được xem lúc

Kafka Consumer Concepts - Consumer Groups và Partition Rebalance

0 0 5

Người đăng: Nguyễn Trung Nam

Theo Viblo Asia

1. Mở đầu

Như chúng ta đã thấy ở bài viết trước Consumers và Consumer Groups, các consumer trong một consumer group chia sẻ quyền sở hữu các partition trong các topic mà họ đăng ký. Khi chúng ta thêm một consumer mới vào nhóm, nó sẽ bắt đầu tiêu thụ các message từ những partition trước đó do một consumer khác tiêu thụ. Điều tương tự cũng xảy ra khi một consumer tắt hoặc gặp sự cố; nó sẽ rời khỏi nhóm và các partition mà nó từng tiêu thụ sẽ được tiêu thụ bởi một trong những consumer còn lại. Việc phân bổ lại các partition cho các consumer cũng diễn ra khi các topic mà consumer group đang tiêu thụ được thay đổi (ví dụ, khi quản trị viên thêm các partition mới).

Việc chuyển quyền sở hữu partition từ một consumer sang một consumer khác được gọi là "rebalance" (tái cân bằng). Rebalance rất quan trọng vì nó mang lại khả năng sẵn sàng cao và khả năng mở rộng cho consumer group (cho phép chúng ta dễ dàng và an toàn thêm hoặc xóa consumer), nhưng trong quá trình hoạt động bình thường của hệ thống, nó có thể là điều mà chúng ta không mong muốn nó xảy ra.

2. Các loại rebalance

Có hai loại rebalance, tùy thuộc vào chiến lược phân bổ partition mà consumer group sử dụng:

Eager rebalance

Trong một eager rebalance, tất cả các consumer sẽ dừng việc tiêu thụ, từ bỏ quyền sở hữu tất cả các partition, tái gia nhập vào consumer group và nhận một phân bổ partition hoàn toàn mới. Điều này tạo ra một khoảng thời gian ngắn mà cả nhóm consumer không hoạt động. Độ dài của khoảng thời gian này phụ thuộc vào kích thước của consumer group cũng như một số tham số cấu hình khác. Hình 1 cho thấy eager rebalance có hai giai đoạn rõ rệt: đầu tiên, tất cả các consumer từ bỏ phân bổ partition của mình, và sau khi tất cả hoàn thành việc này và tái gia nhập nhóm, họ nhận được phân bổ partition mới và có thể tiếp tục tiêu thụ. Hình 1.

Cooperative rebalances

Cooperative rebalances (còn gọi là rebalance tăng dần) thường chỉ liên quan đến việc phân bổ lại một tập con nhỏ của các partition từ một consumer sang một consumer khác, đồng thời cho phép các consumer tiếp tục xử lý dữ liệu từ tất cả các partition không bị phân bổ lại. Điều này được thực hiện qua quá trình rebalance trong hai hoặc nhiều giai đoạn. Ban đầu, leader của consumer group thông báo cho tất cả các consumer rằng họ sẽ mất quyền sở hữu đối với một số partition nhất định. Sau đó, các consumer sẽ ngừng tiêu thụ từ các partition này và từ bỏ quyền sở hữu của mình. Trong giai đoạn thứ hai, leader của consumer group phân bổ các partition chưa được gán này cho các chủ sở hữu mới của chúng. Cách tiếp cận tăng dần này có thể mất vài lần lặp lại cho đến khi phân bổ partition ổn định, nhưng nó tránh được tình trạng “dừng toàn bộ” như trong phương pháp eager. Điều này đặc biệt quan trọng trong các nhóm consumer lớn, nơi mà quá trình rebalance có thể mất nhiều thời gian. Hình 2 minh họa cách Cooperative rebalances diễn ra một cách tăng dần và chỉ có một tập hợp con của các consumer và partition tham gia. Hình 2

3. Kết luận

Các consumer duy trì thành viên trong một consumer group và quyền sở hữu các partition được phân bổ cho họ bằng cách gửi tín hiệu "heartbeat" tới một Kafka broker được chỉ định làm nhóm điều phối (broker này có thể khác nhau đối với các consumer group khác nhau). Tín hiệu "heartbeat" được gửi bởi một background thread của consumer, và miễn là consumer gửi tín hiệu này đều đặn, nó được coi là đang hoạt động.

Nếu một consumer ngừng gửi tín hiệu heartbeat đủ lâu, session của nó sẽ hết thời gian chờ, và nhóm điều phối sẽ coi nó là đã chết và kích hoạt quá trình rebalance. Nếu một consumer bị treo và ngừng xử lý thông điệp, sẽ mất vài giây để nhóm điều phối nhận ra rằng không còn tín hiệu heartbeat và quyết định rằng nó đã chết, sau đó kích hoạt rebalance. Trong thời gian đó, không có thông điệp nào sẽ được xử lý từ các partition thuộc về consumer bị lỗi. Khi đóng một consumer một cách gọn gàng, consumer sẽ thông báo cho nhóm điều phối rằng nó sẽ rời khỏi nhóm, và nhóm điều phối sẽ kích hoạt rebalance ngay lập tức, giúp giảm thời gian ngừng xử lý. Các bài viết tiếp theo sẽ thảo luận về các tùy chọn cấu hình điều chỉnh tần suất gửi heartbeat, thời gian chờ của session và các tham số cấu hình khác để tinh chỉnh hành vi của consumer.

4. Bonus

Quy trình phân bổ partitions cho các consumer diễn ra như thế nào?

Khi một consumer muốn tham gia vào một nhóm, nó gửi một yêu cầu JoinGroup đến group coordinator. Consumer đầu tiên tham gia vào nhóm sẽ trở thành nhóm trưởng. Nhóm trưởng nhận được danh sách tất cả các consumer trong nhóm từ group coordinator (bao gồm tất cả những consumer đã gửi heartbeat gần đây và do đó được coi là vẫn đang hoạt động) và chịu trách nhiệm phân bổ một tập hợp các partitions cho từng consumer. Nhóm trưởng sử dụng một triển khai của PartitionAssignor để quyết định partition nào sẽ được xử lý bởi consumer nào.

Kafka có một vài chính sách phân bổ partition tích hợp sẵn, và chúng ta sẽ thảo luận chi tiết hơn trong phần cấu hình ở các bài viết kế tiếp. Sau khi quyết định việc phân bổ partition, nhóm trưởng của nhóm consumer sẽ gửi danh sách phân bổ tới GroupCoordinator, và GroupCoordinator sẽ gửi thông tin này tới tất cả các consumer. Mỗi consumer chỉ nhận được phân bổ của riêng mình — nhóm trưởng là tiến trình duy nhất nắm giữ danh sách đầy đủ các consumer trong nhóm và phân bổ của họ. Quá trình này lặp lại mỗi khi có một đợt rebalance xảy ra.

5. Thông tin kết nối

Nếu anh em muốn trao đổi thêm về bài viết, hãy kết nối với mình qua LinkedIn và Facebook:

Rất mong được kết nối và cùng thảo luận!

Bình luận

Bài viết tương tự

- vừa được xem lúc

Kafka là gì?

Apache Kafka® là một nền tảng stream dữ liệu phân tán. . stream data: dòng dữ liệu, hãy tưởng tượng dữ liệu là nước trong 1 con suối. .

0 0 43

- vừa được xem lúc

001: Message-driven programming với Message broker và Apache Kafka

Bài viết nằm trong series Apache Kafka từ zero đến one. . . Asynchronous programming.

0 0 164

- vừa được xem lúc

002: Apache Kafka topic, partition, offset và broker

Bài viết nằm trong series Apache Kafka từ zero đến one. Nói qua về lịch sử, Kafka được phát triển bởi LinkedIn (các anh em dev chắc chẳng xa lạ gì) và viết bằng ngôn ngữ JVM, cụ thể là Java và Scala.

0 0 153

- vừa được xem lúc

003: Gửi và nhận message trong Apache Kafka

Bài viết nằm trong series Apache Kafka từ zero đến one. . . Nếu muốn các message được lưu trên cùng một partition để đảm bảo thứ tự thì làm cách nào.

0 0 222

- vừa được xem lúc

004: Apache Kafka consumer offset, Broker discovery và Zookeeper

Bài viết nằm trong series Apache Kafka từ zero đến one. 1) Consumer offset.

0 0 130

- vừa được xem lúc

Apache Kafka - Producer - Gửi message đến Kafka bằng kafka-python

Overview. Understand how to produce message and send to the Kafka topic. Architecture. .

0 0 63