43
4
Kafka (Apache Kafka) là một nền tảng dữ liệu phát trực tuyến phân tán ban đầu được LinkedIn phát triển và sau đó được tặng cho Apache Software Foundation, trở thành một dự án cấp cao của Apache. Nó được thiết kế để xử lý các luồng dữ liệu thời gian thực quy mô lớn và hỗ trợ xây dựng các ứng dụng truyền dữ liệu có thông lượng cao, khả năng chịu lỗi. Các đặc điểm của Kafka khiến nó được sử dụng rộng rãi trong thu thập nhật ký, xử lý thời gian thực, kiến trúc hướng sự kiện, giám sát và các lĩnh vực khác.
Sau đây là một số tính năng và khái niệm chính của Kafka:
Nhìn chung, Kafka đóng vai trò quan trọng trong các lĩnh vực dữ liệu lớn, xử lý thời gian thực và luồng dữ liệu. Kiến trúc phân tán mạnh mẽ và các chức năng phong phú của nó khiến nó trở thành nền tảng được nhiều công ty ưa chuộng để xử lý dữ liệu thời gian thực.
Kafka là một nền tảng dữ liệu phát trực tuyến phân tán rất linh hoạt và mạnh mẽ, phù hợp với nhiều tình huống kinh doanh khác nhau. Sau đây là một số cách sử dụng phổ biến và tình huống kinh doanh của Kafka:
Những ngành nào đang sử dụng Kafka:
broker: nút kafka, là nơi cài đặt từng dịch vụ kafka.
nhà sản xuất: nhà sản xuất, người gửi tin nhắn.
người tiêu dùng: người tiêu dùng, đọc tin nhắn.
Zookeeper: Trung tâm thông tin, nơi ghi lại nhiều thông tin khác nhau về Kafka.
controller: Một trong những broker, chịu trách nhiệm quản lý toàn bộ cụm với tư cách là leader. Nếu không thành công, nó sẽ sử dụng ZooKeeper để bầu lại một leader.
Sao chép Phân loại
AR (Bản sao được chỉ định) đề cập đến tập hợp các bản sao được chỉ định cho mỗi phân vùng. Trong Kafka, mỗi phân vùng có thể có nhiều bản sao, một trong số đó được bầu làm người dẫn đầu và những bản sao khác là người theo dõi. AR đề cập đến bộ sưu tập tất cả các bản sao bao gồm cả bản sao dẫn đầu.
ISR (Bản sao đồng bộ): ISR là tập hợp các bản sao được đồng bộ hóa với bản sao chính. Trong Kafka, một phân vùng chủ đề thường có nhiều bản sao, nhưng chỉ những bản sao đồng bộ với bản sao chính mới có thể được coi là thành viên của ISR. Trong những trường hợp bình thường, tất cả các bản sao trong ISR đều được đồng bộ hóa tin nhắn trước khi đạt đến mức cao nhất, do đó đảm bảo tính nhất quán và độ tin cậy của tin nhắn.
OSR (Bản sao không đồng bộ): OSR đề cập đến các bản sao bị tụt hậu so với bản sao chính. Các bản sao này có thể đồng bộ hóa chậm hơn, có thể do độ trễ của mạng hoặc lý do khác. Khi bản sao không đồng bộ với bản chính, nó sẽ được chuyển ra khỏi ISR. Điều này nhằm đảm bảo các bản sao trong ISR luôn đồng bộ với các tin nhắn trước mức nước cao.
Các khái niệm này được sử dụng trong Kafka để quản lý việc phân phối và đồng bộ hóa các bản sao nhằm đảm bảo độ tin cậy và tính nhất quán của dữ liệu.
AR = ISR + OSR.
offset: offset (chỉ mục), vị trí cụ thể của việc tiêu thụ tin nhắn. Mỗi người tiêu dùng có offset riêng.
HW (High Watermark): Ngưỡng nước cao là điểm đánh dấu cho biết vị trí của tin nhắn đã được xác nhận và cam kết. Tất cả các tin nhắn trước HW đều được coi là đã được xử lý và xác nhận. Theo quan điểm của người tiêu dùng, chỉ có những tin nhắn sau mức ngưỡng cao là chưa được xử lý. Mức nước cao nhất chỉ được ghi lại trong ISR (Bản sao đồng bộ) để đảm bảo tính nhất quán và khả năng hiển thị của tin nhắn. Trong một nhóm ISR, tốc độ của mỗi tin nhắn đồng bộ hóa Follower có thể khác nhau và HW luôn trỏ đến vị trí tin nhắn chậm nhất trong số tất cả các ISR.
LEO (Log End Offset): Độ lệch cuối nhật ký là dấu hiệu cho biết độ lệch của tin nhắn tiếp theo trong phân vùng hiện tại. LEO là độ lệch lớn nhất trong số tất cả các bản sao trong phân vùng, bao gồm các bản sao trong ISR và OSR (Bản sao không đồng bộ). LEO chỉ ra vị trí của các tin nhắn trong phân vùng chưa được sử dụng.
Tóm lại, HW là vị trí của các tin nhắn đã xác nhận và cam kết, được sử dụng để đảm bảo tính nhất quán và khả năng hiển thị của tin nhắn. LEO là độ lệch của tin nhắn tiếp theo trong phân vùng, được sử dụng để chỉ ra vị trí của tin nhắn chưa được xử lý. Hai độ lệch này đóng vai trò quan trọng trong Kafka và ảnh hưởng đến quá trình xử lý và sử dụng tin nhắn.
Vậy mối quan hệ giữa ba điều này là gì?
Ví dụ, khi số lượng bản sao là 3, giá trị LEO sẽ được cập nhật sau khi tin nhắn được gửi đến Leader A. Follower B và Follower C cũng sẽ kéo tin nhắn từ Leader A theo thời gian thực để tự cập nhật. HW biểu thị độ dịch chuyển logarit đạt được bởi A, B và C cùng lúc, tức là giá trị có LEO nhỏ nhất trong số A, B và C. Do độ trễ giữa B và C khi kéo tin nhắn của A, HW thường nhỏ hơn LEO, tức là LEO>=HW.
Mỗi chủ đề trong Kafka có thể có nhiều phân vùng. Mỗi phân vùng tạo một thư mục trên broker nơi nó được đặt. Mỗi phân vùng được chia thành nhiều phân đoạn (Phân đoạn tương đương với việc chia các tin nhắn lớn thành nhiều tệp để ngăn các tệp tin nhắn quá lớn và gây ra tốc độ truy xuất chậm). Mỗi phân đoạn có hai tệp log & index. Tệp nhật ký lưu trữ tin nhắn theo trình tự và phân đoạn chỉ mục lưu trữ tin nhắn trong tệp chỉ mục được đặt tên trực tiếp theo độ lệch của tin nhắn đầu tiên trong phân đoạn hiện tại.
Nhật ký: Kafka sử dụng nhật ký để lưu trữ tin nhắn và mỗi phân vùng đều có một nhật ký tương ứng. Nhật ký là một chuỗi thông điệp được sắp xếp theo thứ tự và không thể thay đổi. Bất cứ khi nào có tin nhắn mới đến, chúng sẽ được thêm vào cuối nhật ký của phân vùng, tạo thành một phân đoạn nhật ký phát triển dần dần. Mỗi phân đoạn nhật ký có kích thước cố định, khi đạt đến giới hạn kích thước, phân đoạn nhật ký đó sẽ bị đóng lại và một phân đoạn nhật ký mới sẽ được tạo ra.
Hoạt động thêm nhật ký rất hiệu quả vì nó chỉ yêu cầu thêm tin nhắn mới vào cuối phân đoạn nhật ký và không yêu cầu di chuyển dữ liệu hiện có. Vì nhật ký không thể thay đổi nên một khi tin nhắn đã được viết thì không thể thay đổi hoặc xóa nó. Tính năng này đảm bảo tính bền vững và không thay đổi của dữ liệu Kafka.
Chỉ mục tin nhắn: Chỉ mục tin nhắn là thành phần quan trọng được sử dụng để tăng tốc tìm kiếm tin nhắn. Mỗi phân đoạn nhật ký có một chỉ mục tin nhắn tương ứng, lưu trữ ánh xạ giữa một số độ lệch tin nhắn quan trọng và độ lệch vật lý. Chỉ mục cho phép Kafka nhanh chóng xác định vị trí các tin nhắn ở các vị trí cụ thể mà không cần phải quét toàn bộ nhật ký từng cái một.
Chỉ mục tin nhắn thường được lưu trữ trong bộ nhớ và được chia thành hai phần: chỉ mục bộ nhớ và chỉ mục đĩa. Chỉ mục trong bộ nhớ chứa ánh xạ giữa một phần của độ lệch tin nhắn và vị trí vật lý của nó trong nhật ký, cho phép thực hiện hầu hết các thao tác tra cứu tin nhắn phổ biến trong bộ nhớ rất nhanh chóng. Chỉ mục đĩa chứa thông tin chỉ mục đầy đủ, nghĩa là toàn bộ dữ liệu chỉ mục không cần phải được tải vào bộ nhớ mà được tải khi cần, giúp tiết kiệm không gian bộ nhớ.
Thông qua lập chỉ mục tin nhắn, Kafka có thể nhanh chóng xác định vị trí tin nhắn để sử dụng, theo dõi và xử lý. Điều này rất quan trọng để hỗ trợ xử lý dữ liệu thông lượng cao và tiêu thụ theo thời gian thực.
Người tiêu dùng nhận được tin nhắn với độ lệch = 6.
Trung tâm cá nhân
Bài viết phát hành
từ bỏ 0000000000000000000 Trong phân khúc 00000000000000000000.chỉ số Tìm giá trị Vị trí của offset = 6 00000000000000000000.nhật ký Tìm trực tiếp byte offset 150 và bắt đầu đọc tin nhắn phân đoạn.byte tham số), phân đoạn nhật ký sẽ bị đóng và được coi là "không hoạt động". Các phân đoạn nhật ký không hoạt động sẽ bị xóa mà không ảnh hưởng đến các lần ghi đang diễn ra. Bằng cách này, các tin nhắn cũ sẽ được xóa và giải phóng dung lượng đĩa. phân đoạn.ms tham số. Khi một phân đoạn nhật ký bị đóng, nếu thời gian tạo của nó vượt quá thời gian lưu giữ này, nó sẽ bị xóa. Điều này đảm bảo dữ liệu cũ không còn cần thiết sẽ được dọn dẹp kịp thời. giữ lại.ms tham số. Nếu một chủ đề có thời gian lưu giữ được thiết lập và các tin nhắn có dấu thời gian cũ hơn thời gian lưu giữ bị xóa, thì các tin nhắn đó cũng sẽ bị xóa. Chiến lược này đảm bảo rằng các tin nhắn không còn cần thiết trong chủ đề sẽ được tự động dọn sạch. chính sách dọn dẹp Các tham số được thiết lập thành nhỏ gọn ), Kafka sẽ giữ lại tin nhắn mới nhất cho mỗi khóa và các tin nhắn cũ hơn sẽ bị xóa. Chiến lược này giữ lại trạng thái mới nhất của mỗi khóa và phù hợp để lưu trữ thông tin trạng thái. Trong Kafka, đơn vị nhỏ nhất của chính sách xóa là phân đoạn nhật ký. Khi điều kiện xóa được đáp ứng, Kafka sẽ xóa toàn bộ phân đoạn nhật ký không còn cần thiết nữa, bao gồm dữ liệu tin nhắn và dữ liệu chỉ mục tương ứng.
Cuối cùng, bài viết này về Kafka-Basics kết thúc tại đây. Nếu bạn muốn biết thêm về Kafka-Basics, vui lòng tìm kiếm các bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .
43
4
0
Tôi gặp lỗi sau khi khởi động Kafka-Server trên máy Windows của mình. Tôi đã tải xuống Scala 2.11 - kafka_2.11-2.1.0.tgz từ liên kết sau: https://kafka.ap
Về hàng đợi tin nhắn Apache-Kafka. Tôi đã tải xuống Apache Kafka từ trang tải xuống Kafka. Tôi đã giải nén nó vào /opt/apache/installed/kafka
Giả sử tôi có chủ đề về ô tô của Kafka. Tôi cũng có một nhóm người tiêu dùng mang tên cars-consumers đăng ký theo dõi chủ đề về ô tô. Nhóm người tiêu dùng ô tô hiện đang ở mức bù trừ 89. Khi tôi bây giờ xóa xe
Tôi muốn biết phương pháp nào tốt nhất cho tôi: Kafka stream hay Kafka consumer api hay Kafka connect? Tôi muốn đọc dữ liệu từ một chủ đề, sau đó xử lý và ghi vào cơ sở dữ liệu. Vì vậy, tôi đã viết người tiêu dùng, nhưng tôi nghĩ tôi có thể viết phản hồi luồng Kafka
Tôi đã làm việc trên một số ứng dụng luồng Kafka và ứng dụng người dùng Kafka. Cuối cùng, luồng Kafka không gì khác hơn là người tiêu dùng sử dụng các sự kiện thời gian thực từ Kafka. Vì vậy, tôi không thể hiểu khi nào nên sử dụng luồng Kafka hoặc tại sao chúng ta nên sử dụng
Sự khác biệt giữa Kafka Acknowledgement và Kafka consumer commitSync() là gì? Cả hai đều được sử dụng để quản lý offset thủ công và muốn cả hai hoạt động đồng bộ. Xin hãy hỗ trợ câu trả lời tốt nhất bằng spring-kafka
Làm thế nào để ủy quyền các yêu cầu của nhà sản xuất Apache Kafka trên các nhà môi giới Kafka và chuyển hướng đến một cụm Kafka riêng biệt? Trong trường hợp cụ thể của tôi, không thể cập nhật ứng dụng khách ghi vào cụm này. Điều này có nghĩa là không thể: Cập nhật máy khách
Tôi cần đặt tên cho người dùng của mình trong Kafka 10 giống như tôi đã làm trong Kafka 8 vì tôi có các tập lệnh đánh hơi và sử dụng thông tin này thêm nữa. Rõ ràng, tên mặc định của consumer.id đã thay đổi (và hiện cũng được hiển thị riêng biệt
1. Tổng quan Chúng ta có thể thấy có một nút /log_dir_event_notification/ trong dữ liệu zk. Đây là một nút duy trì số sê-ri. Vai trò của nút này trong Kafka là: Khi LogDir trên Broker xuất hiện
Tôi đang sử dụng lệnh sau: bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test.topic --property
Tôi đang gặp khó khăn trong việc hiểu một số khái niệm về Kafka trong Java Spring Boot. Tôi muốn kiểm tra người dùng với một nhà môi giới Kafka thực sự chạy trên máy chủ có một số nhà sản xuất đang viết/đã viết dữ liệu cho nhiều chủ đề khác nhau. Tôi muốn phục vụ
Kịch bản của tôi là tôi đang sử dụng nhiều chủ đề Kafka với tiền tố chung (ví dụ house.door, house.room) và sử dụng API mẫu chủ đề biểu thức chính quy của luồng Kafka để sử dụng tất cả các chủ đề. Mọi thứ trông ổn cả, tôi hiểu rồi
Có cách nào để lấy phiên bản cụm Kafka theo phương pháp lập trình không? Ví dụ: sử dụng API AdminClient. Tôi muốn xác định phiên bản Kafka Cluster trong ứng dụng người tiêu dùng/nhà sản xuất. Câu trả lời tốt nhất không thể được tìm thấy tại thời điểm này
Bất cứ khi nào tôi thử khởi động lại Kafka thì nó lại trả về lỗi sau. Khi tôi xóa /tmp/kafka-logs, vấn đề sẽ được giải quyết, nhưng nó cũng xóa chủ đề của tôi. Có cách nào để khắc phục lỗi này không? LỖI Lỗi trong khi
Tôi là người dùng mới của Apache Kafka và tôi vẫn đang tìm hiểu về các chức năng bên trong. Trong trường hợp sử dụng của tôi, tôi cần tăng số lượng phân vùng của một chủ đề từ máy khách Kafka Producer một cách linh hoạt. Tôi tìm thấy những câu hỏi tương tự khác về việc tăng kích thước phân vùng
Theo tài liệu của Kafka, một cách để thực hiện việc này là thông qua kafka.tools.MirrorMaker. Tuy nhiên, tôi cần sao chép một chủ đề (ví dụ như thử nghiệm với 1 phân vùng) (nội dung và siêu dữ liệu của nó) từ sản xuất sang máy chủ mà không cần kết nối
Tôi đã cấu hình 3 kafka trong một cụm và đang cố gắng sử dụng nó với spring-kafka. Nhưng sau khi giết thủ lĩnh Kafka, tôi không thể gửi thêm tin nhắn nào vào hàng đợi nữa. Tôi sẽ spring.kafka.bo
Trình kết nối Kafka Sink của tôi đọc từ nhiều chủ đề (10 tác vụ được cấu hình) và xử lý 300 bản ghi từ tất cả các chủ đề. Tùy thuộc vào thông tin được lưu giữ trong mỗi bản ghi, trình kết nối có thể thực hiện một số hành động nhất định. Sau đây là ví dụ về cặp khóa-giá trị trong bản ghi kích hoạt:
Tôi có mã luồng kafka sau public class KafkaStreamHandler implements Processor{ private ProcessorConte
Khi ứng dụng kafka-streams đang chạy và Kafka đột nhiên ngừng hoạt động, ứng dụng sẽ chuyển sang chế độ "chờ", gửi nhật ký cảnh báo về luồng người dùng và luồng nhà sản xuất không thể kết nối và khi Kafka hoạt động trở lại, mọi thứ (về mặt lý thuyết) sẽ trở lại bình thường.
Tôi là một lập trình viên xuất sắc, rất giỏi!