1. Những điều cần biết trước khi tìm hiểu và khám phá Kafka
Publish/Subscribe messaging
Trước khi thảo luận về các chi tiết cụ thể của Apache Kafka, chúng ta cần hiểu rõ cấu tạo của pub/sub messaging và tại sao nó lại quan trọng .Publish/subscribe messaging là một pattern mà đặc trưng bởi việc gửi (publisher) data (message) mà ko chỉ định người nhận rõ ràng. Thay vào đó người gửi sẽ phân loại tin nhắn thành các lớp và bằng cách nào đó mà người nhận (subscriber) phải đăng kí vào lớp nhất định để nhận tin nhắn ở lớp đấy. Hệ thống pub/sub thường có một broker (nhà phân phối), là trung tâm nơi mà các message được phân phối.
Bắt đầu như thế nào nhỉ
Có rất nhiều use case cho Pub / sub, đơn thuần nhất là hãy mở màn với một hàng đợi tin nhắn ( message queue ) hay những kênh tiếp xúc giữa những tiến trình ( interprocess communication channel ). Ví dụ : bạn tạo một ứng dụng cần gửi tài liệu để theo dõi những hoạt động giải trí của website ví dụ điển hình như vậy bạn tạo liên kết trực tiếp từ website của mình đến một ứng dụng hoàn toàn có thể hiển thị số liệu đó lên một bảng để hoàn toàn có thể theo dõi. ví dụ như trong hình đây
Đây chỉ là một ví dụ đơn giản khi mới bắt đầu với việc theo dõi dữ liệu. Về sau bạn quyết định thử phân tích dữ liệu trong thời gian dài và vs mô hình hiện tại thì hoạt động không tốt. Thế nên bạn sẽ bắt đầu cần một service mà có thể nhận các số liệu, lưu trữ chúng, thống kê chúng. Để hỗ trợ điều này, bạn sửa đổi ứng dụng của mình để có thể gửi dữ liệu cho cả hai hệ thống. Vì thế bây giờ bạn có thêm các ứng dụng mới mà sẽ tạo ra dữ liệu .Và đương nhiên nó cũng cần phải tạo kết nối giống như service trước. Dần dần do nhu cầu mà bạn sẽ có nhiều ứng dụng và service để phục vụ các mục đích khác nhau
( ôi mắt của tôi )
Sự chưa ổn của kỹ thuật kiến thiết xây dựng mạng lưới hệ thống này là rõ ràng, vì thế bạn quyết định hành động phải làm gì đó. Bạn thiết lập một ứng dụng duy nhất nhận tài liệu từ tổng thể những ứng dụng ngoài và cung ứng một sever để duy trì và truy vấn những tài liệu đó cho bất kể mạng lưới hệ thống nào cần chúng .
Individual Queue Systems ( hệ thống xếp hàng cá nhân )
Tại cùng một thời gian bạn muốn thực thi những hoạt động giải trí khác như kiểm tra hay cung ứng những hành vi của người dùng trên website của bạn cho những nhà tăng trưởng ML để thu tập và nghiên cứu và phân tích thói quen người mua. Và rồi bạn nhận ra sự giống nhau của những mạng lưới hệ thống đó và hình dưới đây biểu lộ tới 3 quy mô pub / sub systems
Bằng cách này sẽ tốt hơn nhiều là tận dụng những liên kết point to point nhưng nó lại sống sót nhiều sự tái diễn. Giả sử như công ty của bạn đang duy trì nhiều mạng lưới hệ thống queuing data ( tổng thể đều có lỗi và số lượng giới hạn riêng ). Bạn cũng biết rằng sẽ sớm có nhiều trường hợp sử dụng message mới trong tương lai. Vì thế bạn muốn có một mạng lưới hệ thống tập trung chuyên sâu duy nhất được cho phép tạo ra chung một loại tài liệu mà hoàn toàn có thể tăng trưởng khi doanh nghiệp của bạn tăng trưởng
Kafka là gì ?
Apache Kafka là một mạng lưới hệ thống publish / subscribe messaging được phong cách thiết kế để xử lý yếu tố này. Nó thường được miêu tả như thể một mạng lưới hệ thống “ phân phối những commit log ” hay gần đây còn đc gọi là một “ nền tảng phân phối stream ”. Hiểu nôm na là một mạng lưới hệ thống file hoặc cơ sở tài liệu về commit log được phong cách thiết kế để cung ứng một bản ghi vững chắc về toàn bộ những transaction để hoàn toàn có thể tạo nên tính đồng nhất của mạng lưới hệ thống, tài liệu trong Kafka được tàng trữ vĩnh viễn, theo thứ tự. Ngoài ra, tài liệu hoàn toàn có thể được phân phối trong mạng lưới hệ thống để phân phối những giải pháp bảo vệ hay bổ trợ để chống lại những lỗi mạng lưới hệ thống khiến tài liệu ko đồng điệu, cũng như những năng lực để scaling hiệu suất .
Messages and Batches
Đơn vị dữ liệu trong Kafka được gọi là message .Nếu bạn tiếp cận Kafka từ góc nhìn của nền tảng cơ sở dữ liệu, bạn có thể nghĩ về message tương tự như một row hoặc một record.Một message chỉ đơn giản là một mảng byte, vì vậy dữ liệu chứa trong đó không có định dạng cụ thể hoặc ý nghĩa. Một message có thể có một tùy chọn bit of metadata, được gọi là một khóa ( nghĩa là cái bit này là khóa của metadata :v ). Khóa này cũng là một mảng byte và cũng giống như message nó không có ý nghĩa cụ thể nào cả.Các key được sử dụng khi message được ghi vào các phân vùng khác nhau một cách dễ kiểm soát hơn. Đơn giản nhất là tạo ra một hàm băm nhất quán của key và sau đó cho vào phân vùng có số là kết quả sau khi băm của key. Điều này đảm bảo rằng các tin nhắn có cùng khóa luôn được ghi vào các vùng giống nhau.
Để hiệu quả, message được viết vào Kafka theo đợt( Batches ). batch chỉ là một tập hợp các message, tất cả chúng đang được tạo ra cho cùng một topic ( chủ đề ) và partition ( phân vùng) .Cứ mỗi message mà cứ chạy riêng lẻ trên mạng thì chi phí quá cao vì thế việc gộp các message này thành một lô ( Batches ) làm giảm thiểu chi phí này. Tất nhiên, đây là sự đánh đổi giữa độ trễ và thông lượng ,cũng chỉ là 2 mặt của một đồng xu thôi các lô càng lớn càng nhiều message sẽ phải đợi cho đủ lô mới đc gửi như thế độ trễ sẽ lớn. Các lô cũng thường được nén vì vậy cung cấp khả năng truyền và lưu trữ dữ liệu hiệu quả hơn
Schemas
Mặc dù những thông điệp là những mảng byte không có ý nghĩa do đó tất cả chúng ta nên vận dụng cấu trúc hoặc lược đồ ( shemas ) cho nội dung message để hoàn toàn có thể dễ hiểu hơn. Có nhiều tùy chọn có sẵn cho message schema, tùy thuộc vào ứng dụng của bạn cần gì. Các mạng lưới hệ thống đơn thuần, ví dụ điển hình như ( JSON ) và ( XML ), rất dễ sử dụng và dễ đọc với con người. Tuy nhiên, chúng thiếu những tính năng như giải quyết và xử lý kiểu can đảm và mạnh mẽ và năng lực thích hợp giữa những phiên bản schemas. Nhiều nhà tăng trưởng Kafka ủng hộ việc sử dụng Apache Avro, một framework tuần tự hóa khởi đầu được tăng trưởng cho Hadoop. Avro cung ứng một định dạng tuần tự hóa nhỏ gọn, những Schemas tách biệt với tải trọng của message và không nhu yếu phải code lại khi chúng biến hóa .
Một định dạng tài liệu đồng điệu rất quan trọng trong Kafka, vì nó được cho phép viết và đọc những message bị tách rời. Khi những tác vụ này được tích hợp ngặt nghèo, những ứng dụng ĐK để nhận message phải được update để giải quyết và xử lý định dạng tài liệu mới song song với định dạng cũ. Sau đó, những ứng dụng cần bắn những message mới được update để sử dụng định dạng mới. Bằng cách sử dụng những shemas được xác lập rõ những message trong Kafka hoàn toàn có thể được hiểu thuận tiện hơn. ( phù nếu mà khó hiểu quá thì cứ nghĩ nó giống như rpc gửi tài liệu và cần file proto để định dạng lại tài liệu khi nhận ý )
Topics and Partitions (chủ đề và phân vùng )
Message trong Kafka được phân loại thành những topics. Ví dụ gần nhất với topic đó chính ra table trong db hay thư mục trong filesystem. Các topic được chia nhỏ ra thành những phân vùng nhỏ. Quay trở lại miêu tả về commit log, một phân vùng được hiểu là một bản ghi duy nhất của những message. Message được viết theo kiểu mục lục và được đọc theo thứ tự từ đầu đến cuối. Lưu ý rằng vì một topic thường có nhiều phân vùng, không có gì bảo vệ việc sắp xếp thời hạn của những message trên topic trong một phân vùng là duy nhất. Hình bên dưới cho thấy một topic có bốn phân vùng, với việc những message đang được thêm vào cuối mỗi phân vùng. Mỗi phân vùng hoàn toàn có thể được tàng trữ trên một sever khác nhau, điều đó có nghĩa là một topic hoàn toàn có thể được scale theo chiều ngang trên nhiều sever để cung ứng hiệu suất vượt xa năng lực của một sever duy nhất .
Stream là thuật ngữ thường được sử dụng khi nói về tài liệu trong những mạng lưới hệ thống như Kafka. Thông thường, một stream được coi là một single topic của tài liệu, bất kể số lượng phân vùng trong topic. Điều này bộc lộ một stream tài liệu duy nhất chuyển từ producers sang consumers. Cách đề cập đến những message này là khá phổ cập khi miêu tả việc giải quyết và xử lý củastream, đó là khi 1 số ít framework như Kafka Streams, Apache Samza và Storm, hoạt động giải trí trên những message theo thời hạn thực. Phương pháp hoạt động giải trí này hoàn toàn có thể được so sánh với cách những framework ngoại tuyến, đơn cử là Hadoop, được phong cách thiết kế để hoạt động giải trí trên những tài liệu đã đc giải quyết và xử lý xong ( ko phải real time như những những trên ) .
Producers and Consumers
Kafka client là những người dùng mạng lưới hệ thống Kafka và có 2 loại cơ bản : producers và consumers. Ngoài ra còn có những advandced client APIs – Kafka Connect API để tích hợp những tài liệu và Kafka Streams cho việc stream processing .
Producers là thành phần tạo ra những message. Trong mạng lưới hệ thống pub / sub hoàn toàn có thể đc gọi là publishers hay writers. Nói chung là nó sẽ tạo message và cung ứng cho một topic đơn cử. Theo mặc định, producers không chăm sóc việc message được cho vào phân vùng nào của topic. Trong 1 số ít trường hợp, producer sẽ gửi message đến những phân vùng đơn cử. Điều này thường được thực thi bằng cách sử dụng key và trình phân vùng sẽ tạo ra một hàm băm của khóa và ánh xạ nó tới một phân vùng đơn cử. Điều này bảo vệ rằng toàn bộ những message được tạo bằng một khóa đã cho sẽ được ghi vào cùng một phân vùng duy nhất .
Consumers là thành phần đọc những message. Trong những mạng lưới hệ thống pub / sub khác, consumers hoàn toàn có thể gọi là subscribers hoặc là reader. Consumers ĐK một hoặc nhiều topic và đọc những message theo thứ tự mà chúng được tạo ra. Consumers giữ việc theo dõi những message mà nó đã đăng kí bằng cách theo dõi những offset ( là giá trị số nguyên tăng lên mỗi khi message đc tạo ra ). Mỗi message trong một phân vùng đều có số này là duy nhất. Việc sử dụng giá trị offset này giúp consumers hoàn toàn có thể dừng hay khi khởi động lại hoàn toàn có thể đọc tiếp những message mà không bị mất vị trí đã đọc được trước đó. Ngoài ra những consumers sẽ hoạt động giải trí như một group. Theo cách này, consumer hoàn toàn có thể lan rộng ra theo chiều ngang để giải quyết và xử lý hết những topic với số lượng lớn những message. Ngoài ra, nếu một consumer ngừng hoạt động giải trí, những thành viên còn lại của nhóm sẽ cân đối lại những phân vùng đang được sử dụng và tiếp quản việc của thành viên bị ngừng hoạt động giải trí .
Brokers and Clusters
Một máy chủ Kafka được gọi là broker. Broker nhận đc message từ producers, gán offsets cho chúng và lưu trữ chúng trên ổ đĩa. Nó cũng phục vụ các comsumer, đáp ứng yêu cầu tìm phân vùng và trả lại các message đã đc commit trong ổ đĩa. Tuỳ vào phần cứng cụ thể và các đặc điểm về hiệu xuất của nó mà một broker có thể xử lý hàng ngàn phân vùng và hàng triệu message mỗi giây .
Kafka brokers được thiết kế để hoạt động như một phần của một cluster. Trong một cụm các broker sẽ có một broker hoạt động như cluster controller ( nó được bầu tự động từ các thành viên trong cluster đó). Controller chịu trách nhiệm cho các hoạt động quản trị, bao gồm việc gán các phân vùng cho các broker và giám sát các lỗi của chúng. Một phân vùng mà được sở hữu bởi một broker duy nhất trong cluster thì broker đó được gọi là leader của phân vùng đó. Một phân vùng có thể được gán cho nhiều broker, điều này sẽ dẫn đến phân vùng có thể được sao chép. Điều này cho phép một broker khác trở thành leader nếu broker leader hiện tại sập.
Tính năng chính của Apache Kafka là năng lực lưu giữ message trong một khoảng chừng thời hạn dài. Các broker được thông số kỹ thuật mặc định để giữ lại message trong topic một khoảng chừng thời hạn ( ví dụ : 7 ngày ) hoặc cho đến khi topic đạt đến size nhất định tính bằng bytes ( ví dụ : 1 GB ). Khi đạt đến những số lượng giới hạn này, những message sẽ hết hạn và bị xóa để lưu giữ những message mới. Các topic riêng không liên quan gì đến nhau cũng hoàn toàn có thể được thông số kỹ thuật việc lưu giữ riêng không liên quan gì đến nhau để những message sẽ được tàng trữ miễn là chúng còn hữu dụng. Ví dụ : một message theo dõi hoàn toàn có thể được giữ lại trong vài ngày, trong khi những message ít quan trọng hơn sẽ bị xóa và thay thế sửa chữa chỉ trong vài giờ .
Multiple Clusters
Khi Kafka tăng trưởng, thường sẽ hiệu suất cao hơn nếu có nhiều Cluster. Chúng ta có một vài nguyên do để hiểu tại sao điều này lại hiệu suất cao :
Phân chia những loại dữ liệuTách ra do những nhu yếu về bảo mậtNhiều datacenter hơn ( khắc phục việc bị 1 lỗi khiến cả mạng lưới hệ thống sụp đổ )
Khi thao tác với nhiều datacenter nói riêng, thường thì những message phải được tạo những bản sao giữa chúng. Ví dụ : nếu người dùng biến hóa thông tin công khai minh bạch trong hồ sơ của họ, đổi khác đó sẽ cần được update trên bất kỳ datacenter nào. Tuy nhiên những chính sách sao chép trong những cluster Kafka được phong cách thiết kế để hoạt động giải trí trong một cluster duy nhất, không phải giữa nhiều cluster .
Kafka có một tool là MirrorMaker, được sử dụng cho mục đích này. Về cốt lõi, MirrorMaker chỉ đơn giản là một Kafka consumer và producer được liên kết với nhau bằng 1 hàng đợi ( queue ) để message từ một cluster này được cung cấp cho một cluster khác. Hình bên dưới cho thấy một ví dụ về kiến trúc sử dụng MirrorMaker, tổng hợp các message từ hai local clusters thành một cụm tổng hợp, sau đó sao chép cụm đó sang các datacenter khác.
Why Kafka
Có nhiều lựa chọn để tạo mạng lưới hệ thống publish / subscribe messaging systems, vậy điều gì khiến Apache Kafka là một lựa chọn tốt ?
Multiple Producers
Kafka hoàn toàn có thể giải quyết và xử lý liền mạch nhiều producers, mặc dầu clients đó đang sử dụng nhiều topic hoặc cùng một topic. Điều này tạo nên một hệ thống lý tưởng để tổng hợp tài liệu từ nhiều frontend. Ví dụ : một website phân phối nội dung cho người dùng trải qua nhiều microservice như vậy nghĩa là sẽ có nhiều producers bắn tài liệu tích lũy từ những hoạt động giải trí của ng dùng do đó sẽ có nhiều topic như vậy sẽ nhiều những định dạng, tuy nhiên Kafka hoàn toàn có thể xử lý toàn bộ những service và hoàn toàn có thể ghi và sử dụng một định dạng chung cho tổng thể. Consumer application hoàn toàn có thể nhận một luồng tài liệu mà không cần phải nhận từ nhiều topic .
Multiple Consumers
Ngoài việc hoàn toàn có thể thêm nhiều producers, Kafka còn được phong cách thiết kế cho nhiều consumers để đọc bất kể ( steam of message ) dòng tin nhắn nào mà không tác động ảnh hưởng lẫn nhau. Điều này có vẻ như trái ngược vs queuing systeam nghĩa là trong hàng đợi đó khi một tin nhắn được sử dụng bởi một consumer, thì nó không khả dụng với những consumer khác. Multiple Kafka consumers hoàn toàn có thể chọn hoạt động giải trí như một phần của nhóm và san sẻ một stream, bảo vệ rằng hàng loạt nhóm giải quyết và xử lý message đã cho chỉ trong một lần .
Disk-Based Retention (Duy trì dựa trên đĩa)
Kafka không chỉ có thể xử lý multiple consumers, mà còn có có thể lưu giữ tin nhắn khá lâu ( duy trì bền ) vì consumer không phải lúc nào cũng cần làm việc theo thời gian thực. Messages được commit vào ổ đĩa, và sẽ được lưu trữ với các quy tắc nhất định. Các tùy chọn này có thể là được chọn trên cơ sở từng topic, cho phép các luồng message khác nhau có sự khác biệt về số lượng duy trì phụ thuộc vào nhu cầu của consumer. Duy trì bền có nghĩa là nếu consumer tụt lại phía sau, do xử lý chậm hoặc bị rối loạn trong khi truyền cũng không có nguy cơ bị mất dữ liệu. Nó cũng có nghĩa là bảo trì có thể được thực hiện trên consumer, lấy các ứng dụng ngoại tuyến trong một khoảng thời gian ngắn, không quan tâm về các message sao lưu trên producer hoặc bị mất. consumer có thể bị dừng lại và các message sẽ được giữ lại ở Kafka. Điều này cho phép nó khởi động lại và nhận các tin nhắn xử lý nơi chúng thoát mà không mất dữ liệu.
Scalable
Khả năng mở rộng linh hoạt của Kafka sẽ giúp bạn dễ dàng xử lý bất kỳ lượng dữ liệu nào. Người dùng có thể bắt đầu với một broker duy nhất như một proof of concept, mở rộng từ một phát triển từ một cluster nhỏ gồm 3 brokers rồi chuyển sang với một mô hình lớn hơn với một cluster lớn với hàng trăm ngàn broker phát triển theo thời gian khi dữ liệu tăng lên. Scale có thể được thực hiện bên trong khi cluster đang online mà không ảnh hưởng đến tính khả dụng của toàn bộ hệ thống. Điều này cũng có nghĩa là một nhóm nhiều broker có thể xử lý sự thất bại của một broker riêng lẻ và tiếp tục phục vụ khách hàng. Các cluster gặp nhiều thất bại hơn có thể được cấu hình với các yếu tố sao chép cao hơn.
High Performance
Tất cả những tính năng này tích hợp với nhau để biến Apache Kafka thành một mạng lưới hệ thống publish / subscribe messaging với hiệu suất tuyệt vời dưới tải trọng cao. Producers, consumers và brokers đều hoàn toàn có thể lan rộng ra quy mô để giải quyết và xử lý những luồng message rất lớn một cách thuận tiện .
The Data Ecosystem (hệ sinh thái dữ liệu)
Apache Kafka cung ứng mạng lưới hệ thống giám sát cho hệ sinh thái data. Nó mang message giữa những thành phần khác nhau của hạ tầng, phân phối một giao diện đồng nhất cho tổng thể client. Khi được phối hợp với một mạng lưới hệ thống để cung ứng những message, producers và consumers không còn nhu yếu liên kết ngặt nghèo hoặc liên kết trực tiếp dưới bất kỳ hình thức nào. Các thành phần hoàn toàn có thể được thêm và xóa khi gặp những trường hợp khác nhau, và những producers không cần phải chăm sóc đến việc ai đang sử dụng tài liệu hoặc số lượng ứng dụng lấy tài liệu .
Use Cases
Activity tracking
Messaging
Kafka cũng được sử dụng để gửi tin nhắn, nơi những ứng dụng cần gửi thông tin ( như email ) cho người dùng. Những ứng dụng đó hoàn toàn có thể tạo tin nhắn mà không cần phải chăm sóc đến định dạng hoặc cách tin nhắn sẽ thực sự được gửi. Sau đó, một ứng dụng hoàn toàn có thể đọc toàn bộ những tin nhắn được gửi và giải quyết và xử lý chúng một cách đồng nhất, gồm có :
Định dạng những messageThu thập nhiều message vào một rồi mới đc gửiÁp dụng tùy chọn của người dùng về cách họ muốn nhận tin nhắn
Sử dụng một ứng dụng duy nhất cho việc này để tránh sự cần thiết phải sao chép chức năng trong nhiều ứng dụng, cũng như cho phép các hoạt động như tổng hợp mà không thể thực hiện được.
Metrics and logging
Kafka cũng lý tưởng để tích lũy những tài liệu và logging. Đây là một tác dụng trong trường hợp là có năng lực nhiều ứng dụng tạo ra cùng loại message. Các ứng dụng public tài liệu tiếp tục cho topic Kafka và những tài liệu này hoàn toàn có thể được sử dụng bởi những mạng lưới hệ thống để theo dõi và cảnh báo nhắc nhở. Họ cũng hoàn toàn có thể được sử dụng trong một mạng lưới hệ thống ngoại tuyến như Hadoop để thực thi nghiên cứu và phân tích dài hạn hơn, ví dụ điển hình như dự báo tăng trưởng. Message hoàn toàn có thể được public theo cùng một cách, và hoàn toàn có thể được được chuyển đến những mạng lưới hệ thống tìm kiếm logging chuyên được dùng như Elastisearch hoặc ứng dụng nghiên cứu và phân tích bảo mật thông tin .
Commit log
Vì Kafka dựa trên khái niệm commit log, những biến hóa cơ sở tài liệu hoàn toàn có thể được public lên Kafka và những ứng dụng hoàn toàn có thể thuận tiện theo dõi luồng này để nhận update trực tiếp khi chúng Open. Luồng biến hóa này cũng hoàn toàn có thể được sử dụng để sao chép những update cơ sở tài liệu vào một mạng lưới hệ thống từ xa hoặc để hợp nhất những đổi khác từ nhiều ứng dụng vào một chính sách xem. Duy trì vĩnh viễn rất có ích ở đây để cung ứng bộ đệm cho đổi khác, có nghĩa là nó hoàn toàn có thể được phát lại trong trường hợp ứng dụng lấy tài liệu bị lỗi. Luân phiên, những topic được nén hoàn toàn có thể được sử dụng để cung ứng năng lực lưu giữ lâu hơn
Oaaa trình làng có vẻ như dài và việc đọc hoàn toàn có thể cải tổ giấc ngủ. Nhưng yên tâm ngay sau đây là phần hướng dẫn thiết lập sẽ có trong bài viết dưới đây :
