Apache Kafka cung cấp 2 loại policy lưu giữ Log như sau:
Lưu giữ Log dựa trên thời gian
Khi thời gian lưu giữ Log được cấu hình sẵn đã đạt tới ngưỡng cho segment, nó sẽ được đánh dấu delete hoặc compaction – phụ thuộc vào policy dọn dẹp log đã được cấu hình trước đó. Theo mặc định, thời gian lưu giữ Log đối với mỗi Segment là 7 ngày.
Dưới đây là các tham số (thứ tự ưu tiên giảm dần) bạn có thể thiết lập trong file Kafka Broker property
Lưu giữ Log dựa trên kích thước file
Trong policy này, chúng ta cấu hình kích thước tối đa của một cấu trúc dữ liệu Log dành cho một topic partition. Một khi kích thước file log đạt tới giá trị giới hạn đã được thiết lập, nó bắt đầu quá trình xóa segment từ phần đuôi của Log. Policy này không được sử dụng phổ biến cho lắm vì nó không cung cấp cho chúng ta khả năng để có được cái nhìn tổng quát về thời gian hết hạn của các messages. Tuy nhiên, khi sử dụng policy này, nó trở nên cực kỳ hữu ích khi chúng ta muốn kiểm soát kích thước của Log khi cluster của chúng ta bị giới hạn về không gian đĩa trống.
Và như vậy, cho đến giờ chúng ta đã hiểu được policy lưu giữ log là gì rồi, một khi khoảng giá trị lưu giữ log đạt tới giới hạn, các policy dọn dẹp log sẽ được thực hiện. Tiếp theo mình sẽ trình bày cho các bạn hiểu về cách Kafka dọn dẹp Log như thế nào.
Policy dọn dẹp Log là gì?
Trong kafka, không giống như các hệ thống message khác, các messages trên một topic không bị xóa ngay lập tức ngay sau khi chúng được consumed. Thay vào đó, cấu hình riêng dành cho mỗi mỗi topic sẽ xác định topic này sẽ có bao nhiêu dung lượng lưu trữ và cách chúng được quản lý như thế nào.
Khái niệm làm cho dữ liệu hết hạn còn được gọi là quá trình dọn dẹp (Cleanup) log. Đây là cấu hình ở cấp độ topic. Điều quan trọng là chúng ta cần phải hạn chế log segment lại để tiếp tục nhận thêm các messages mới nhất.
Các loại policy dọn dẹp Log
Delete policy
Đây là policy dọn dẹp Log mặc định. Nó sẽ loại bỏ các segments cũ khi hết thời gian lưu giữ hoặc đạt tới ngưỡng kích thước bị giới hạn.
Compact Policy
Nó cho phép Log compaction trên một topic. Ý tưởng ở đây là loại bỏ các record của mỗi partition mà có các bản cập nhật mới nhất với cùng primary key. Bằng cách này, log sẽ được đảm bảo có ít nhất một trạng thái cuôĩ cùng đối với mỗi key.
Chúng ta sẽ xem qua hình ảnh bên dưới đây, sơ đồ về log đối với một log compacted topic.
Như bạn có thể thấy ở đây, nó thực hiện quá trình dọn dẹp giá trị V1 đối với key K1 và giữ lại trạng thái mới nhất với giá trị là V4.
Dưới đây là một số cấu hình quan trọng khi sử dụng Log compaction.
delete và compact policy
Chúng ta có thể chỉ định cả hai giá trị là delete và compact cho cleanup.policy tại cùng thời điểm. Trong trường hợp này, log được nén lại, nhưng quá trình dọn dẹp vẫn sẽ tuân thủ theo các thiết lập như: thời gian lưu giữ và giới hạn về mặt kích thước file.
Khi cả hai phương thức trên một khi đã được kích hoạt, việc lập kế hoạch về dung lượng đĩa sẽ trở nên đơn giản hơn khi bạn chỉ có log compacted topic. Tuy nhiên, một số trường hợp sử dụng log compaction phải phụ thuộc vào các messages không bị xóa bởi policy dọn dẹp log, vì vậy bạn hãy nên cân nhắc xem liệu rằng có nên sử dụng cả 2 policy như trên hay không, để sao cho phù hợp với kịch bản triển khai của bạn.
Làm sao để thiết lập policy dọn dẹp log?
Tại phần cấu hình log.cleanup.policy có thể có giá trị là “delete“, “compact” hoặc “compact, delete“
Log cleaner là gì?
Log cleaner thực hiện Log compaction. Log cleaner là các thread chạy ngầm để dọn dẹp log.
Compaction thread hoạt động như thế nào?
1. Đầu tiên nó sẽ chọn log có tỉ lệ phần đầu log đến phần đuôi log lớn nhất.
2. Nó sẽ tạo ra một bản tóm tắt các offset mới nhất đối với mỗi key trong phần đầu và đuôi của log gọi là offset map.
3. Nó copy log từ đầu cho cho đến đuôi để loại bỏ những key đã xuất hiện trước đó trong log. Các segments mới đã được dọn dẹp sẽ được hoán đổi vào trong log ngay lập tức, để không gian đĩa cần thiết chỉ là một phần log segment (không phải là bản sao của log).
4. Bản tóm tắt phần đầu của log (offset map) về cơ bản chỉ là một bảng băm. Nó sử dụng 24 bytes cho mỗi entry. Kết quả là với 8GB bộ đệm của log cleaner, mỗi lần lặp lại quá trình dọn dẹp nó có thể dọn sạch khoảng 365GB phần đầu log (giả sử mỗi message của bạn có dung lương 1KB).
Làm sao để kích hoạt Log cleaner?
Một số câu hỏi thường gặp về Log Cleaner
Không. Quá trình dọn dẹp log không chặn việc đọc dữ liệu và có thể được điều chỉnh để sử dụng không quá một lượng thoughtput I/O đã được cấu hình trước – để tránh ảnh hưởng đến producer và consumer.
Không. Offset đối với mỗi offset không bao giờ thay đổi. Nó là một giá trị định danh vĩnh viễn cho một vị trí trong log, nó chỉ loại bỏ một số message bị trùng lặp key cũ.
Đúng. Một message với một key và null payload được coi như là tombstone message. Log cleaner cũng xóa luôn các tombstone đó luôn.
Xem thêm:
