آشنایی با کافکا

1 مقدمه

امروزه سازمان‌ها قدرت خودشان را از داده‌ها‌ می‌گیرند. ما اطلاعاتی را دریافت می‌کنیم، آن‌ها را تجزیه و تحلیل می‌کنیم، آن‌ها را دستکاری می کنیم و بیشتر به دنبال ایجاد خروجی هستیم. هر برنامه ای داده ایجاد می کند، خواه پیام های لاگ، متریک‌ها، فعالیت کاربران، پیام های خروجی یا چیز دیگری باشد. هر بایت داده داستانی برای گفتن دارد، چیزی اهمیت دارد که به کارهای بعدی که باید انجام شود اطلاع رسانی می کند. برای اینکه بدانیم آن چیست، باید داده‌ها را از جایی که ایجاد می‌شود تا جایی که بتوان آن‌ها را تحلیل کرد، دریافت کنیم. این را هر روز در وب‌سایت‌هایی مانند آمازون می‌بینیم، جایی که کلیک‌های ما روی موارد مورد علاقه ما به توصیه‌هایی تبدیل می‌شوند که کمی بعد به ما نشان داده می‌شوند.

هرچه سریعتر بتوانیم این کار را انجام دهیم، سازمانهای ما می توانند چابک تر و پاسخگوتر باشند. هرچه نیاز برای جابجایی داده‌ها نیازمندی تلاش کمتری باشد ، بیشتر می‌توانیم بر روی کسب‌وکار اصلی تمرکز کنیم. به همین دلیل است که pipeline یک جزء حیاتی در سازمان‌های داده محور است. نحوه انتقال داده ها تقریباً به اندازه خود داده مهم است.

همانگونه که Neil deGrasse Tyson می‌گوید

هر زمانی که دانشمندان با هم موافق نیستند، به این دلیل است که داده‌های کافی نداریم. سپس می‌توانیم درباره نوع داده‌هایی به توافق برسیم. ما داده ها را دریافت می کنیم. و داده ها مشکل را حل می کند. یا من درست می‌گویم، یا شما درست می‌گویید، یا هر دو اشتباه می‌کنیم. و ما ادامه می دهیم.

بنابراین مسئله‌ای که ما در این مستند قصد داریم حل کنیم، مسئله‌ي ارتباط سیستم‌ها از طریق مکانیزم صف است.

به عنوان مثال)

طراحی مبتنی بر تراکنش بسیار مهم است اگر که قصد دارید از خرابی‌ها در امان بمانید مانند خرابی برقی یک سرور می‌توانید از صف پیام رسانی استفاده کنید. تصور کنید که می خواهید سیستم بانکی را از برداشت پول خودپرداز مطلع کنید، و این کار باید دقیقاً یک بار در هر درخواست انجام شود، مهم نیست که چه سرورهایی در وسط موقتاً از کار افتاده اند. سیستم های MQ به شما این امکان را می دهند که تراکنش ها را در چندین پایگاه داده، MQ و سایر سیستم ها هماهنگ کنید.

1-1 الگوی پیام رسانی Publish/Subscribe

قبل از بحث در مورد ویژگی های آپاچی kafka، برای ما مهم است که مفهوم انتشار/اشتراک پیام رسانی و چرایی اهمیت آن را درک کنیم. پیام انتشار/اشتراک الگویی است که مشخص می شود فرستنده (ناشر) یک قطعه داده (پیام) آن را به طور خاص به گیرنده هدایت نمی کند. در عوض، ناشر پیام را به نحوی طبقه بندی می کند و آن گیرنده (مشترک) برای دریافت دسته های خاصی از پیام ها مشترک می شود. سیستم‌های Pub/Sub اغلب یک کارگزار دارند، یک نقطه مرکزی که پیام‌ها در آن منتشر می‌شوند تا این امر را تسهیل کنند.

1-1-1 این الگو چگونه شروع می‌شود

بسیاری از موارد استفاده برای انتشار/اشتراک به همین روش شروع می‌شوند: با یک صف پیام ساده یا کانال ارتباطی میان درون پردازه‌ای. به عنوان مثال، شما یک برنامه کاربردی ایجاد می‌کنید که باید اطلاعات نظارتی را به جایی ارسال کند، بنابراین یک اتصال مستقیم از برنامه خود به برنامه‌ای که متریک‌های شما را روی داشبورد نمایش می‌دهد ایجاد می‌کنید و یکسری متریک‌ها بر روی آن اتصال قرار می‌دهید، همانطور که در زیر مشاهده می‌شود. شکل 1-1.

این یک راه حل ساده برای یک مشکل ساده است که در هنگام شروع کار با مانیتورینگ کار می کند. خیلی زود، تصمیم می گیرید که می خواهید متریک‌های خود را در طولانی مدت تجزیه و تحلیل کنید، و این در داشبورد به خوبی کار نمی کند. شما یک سرویس جدید راه اندازی می کنید که می تواند متریک‌ها را دریافت کند، آنها را ذخیره و تجزیه و تحلیل کند. به منظور پشتیبانی از این امر، برنامه خود را برای نوشتن متریک‌ها برای هر دو سیستم تغییر می دهید. در حال حاضر شما سه برنامه دیگر دارید که متریک‌ها را تولید می کنند، و همه آنها اتصالات یکسانی را با این دو سرویس برقرار می کنند. همکار شما فکر می‌کند که ایده خوبی است که نظرسنجی فعال سرویس‌ها را برای هشدار نیز انجام دهید، بنابراین یک سرور برای هر یک از برنامه‌ها برای ارائه متریک‌ها در صورت درخواست اضافه می‌کنید. پس از مدتی، شما برنامه های بیشتری دارید که از آن سرورها برای دریافت متریک‌های فردی و استفاده از آنها برای اهداف مختلف استفاده می کنند. این معماری می تواند بسیار شبیه شکل 1-2 باشد، با اتصالاتی که ردیابی آنها حتی سخت تر است.

بدهی فنی( زمانی بدهی فنی ایجاد می‌شود که توی طراحی گفتیم فلان نکته‌ی مهم رو بعده‌ها انجام می‌دهیم) ایجاد شده در اینجا واضح است، بنابراین شما تصمیم می گیرید مقداری از آن را بازپرداخت کنید. شما یک برنامه کاربردی راه اندازی می کنید که معیارها را از همه برنامه های موجود در آنجا دریافت می کند، و یک سرور برای پرس و جو از این معیارها برای هر سیستمی که به آنها نیاز دارد ارائه می دهید. این امر پیچیدگی معماری را به چیزی شبیه به شکل 1-3 کاهش می دهد. تبریک می گویم، شما یک سیستم پیام رسانی انتشار-اشتراک ایجاد کرده اید!

1-1-2 سیستم‌های صف مجزا

در همان زمان که شما این جنگ را با متریک به راه انداخته اید، یکی از همکاران شما کار مشابهی را با پیام های لاگ انجام می دهد. یک همکار دیگر بر روی ردیابی رفتار کاربران در وب‌سایت فرانت‌اند کار می‌کند و آن اطلاعات به توسعه‌دهندگانی که روی یادگیری ماشین کار می‌کنند ارائه می‌دهد و همچنین به ایجاد برخی گزارش‌ها برای مدیریت کارها می‌پردازد. همه شما مسیر مشابهی را برای ایجاد سیستم هایی دنبال کرده اید که publisher اطلاعات را از subscriber آن اطلاعات جدا می‌کند. شکل 1-4 چنین زیرساختی را با سه سیستم pub/sub مجزا نشان می دهد.

این مطمئناً بسیار بهتر از استفاده از اتصالات نقطه به نقطه است (مانند شکل 1-2)، اما موارد تکراری زیادی وجود دارد. شرکت شما چندین سیستم را برای صف بندی داده ها نگهداری می کند، که همه آنها باگ ها و محدودیت های خاص خود را دارند. همچنین می دانید که به زودی موارد استفاده بیشتری برای پیام رسانی وجود خواهد داشت. آنچه شما دوست دارید داشته باشید یک سیستم متمرکز واحد است که امکان انتشار انواع عمومی داده ها را فراهم می کند، که با رشد کسب و کار شما رشد خواهند کرد.

2 ورود به دنیای kafka

آپاچی kafka یک سیستم پیام رسانی انتشار/اشتراک است که برای حل این مشکل طراحی شده است. اغلب به عنوان "distributed commit log" یا اخیراً به عنوان "distributing streaming platform" توصیف می شود. یک سیستم فایل یا پایگاه داده commit log طراحی شده است تا یک رکورد بادوام از تمام تراکنش ها فراهم کند تا بتوان آنها را برای ساختن وضعیت یک سیستم، مجدداً منتشر کرد. به طور مشابه، داده‌های درون kafka به‌طور بادوام و به‌ترتیب ذخیره می‌شوند و می‌توانند به‌طور قطعی خوانده شوند. علاوه بر این، داده‌ها را می‌توان در داخل سیستم توزیع کرد تا محافظت‌های اضافی در برابر خرابی‌ها و همچنین فرصت‌های قابل توجهی برای مقیاس‌بندی عملکرد فراهم کند.

2-1 پیام ها و دسته ها(batches)

واحد داده در kafka، پیام نامیده می شود. اگر از عینک پایگاه داده به kafka نگاه کنیم، می‌توانید پیام را شبیه به یک ردیف یا یک رکورد در پایگاه داده دید. یک پیام تا آنجا که به kafka مربوط می شود، صرفاً آرایه ای از بایت است، بنابراین داده های موجود در آن، قالب یا معنای خاصی برای kafka ندارند. یک پیام می‌تواند یک بیت اختیاری از فراداده داشته باشد که به آن کلید می‌گویند. کلید نیز یک آرایه بایتی است و مانند پیام، معنای خاصی برای kafkaندارد. زمانی که قرار است پیام ها به شیوه ای کنترل شده تری روی پارتیشن ها نوشته شوند، از کلیدها استفاده می شود. ساده‌گی چنین طرحی این است که یک هش ثابت از کلید ایجاد کنید و سپس با گرفتن نتیجه hash modulo، تعداد کل پارتیشن ها در رأس را انتخاب کنید. این تضمین می کند که پیام هایی با کلید یکسان همیشه در یک پارتیشن نوشته می شوند.

برای کارایی، پیام‌ها به صورت دسته‌ای در kafka نوشته می‌شوند. یک دسته فقط مجموعه ای از پیام ها است که همه آنها در یک topic و پارتیشن تولید می شوند. یک رفت و برگشت جداگانه در سراسر شبکه برای هر پیام منجر به سربار بیش از حد می شود و جمع آوری پیام ها با هم به صورت دسته ای این را کاهش می دهد. البته، این یک مبادله بین تأخیر و توان عملیاتی است: هر چه دسته‌ها بزرگتر باشند، پیام‌های بیشتری را می‌توان در واحد زمان مدیریت کرد، اما انتشار یک پیام جداگانه بیشتر طول می‌کشد. دسته‌ها نیز معمولاً فشرده می‌شوند که انتقال و ذخیره‌سازی کارآمدتر داده‌ها را به قیمت مقداری قدرت پردازش فراهم می‌کنند.

2-2 طرح واره‌ها یا schema

در حالی که پیام‌ها آرایه‌های بایتی مبهم برای خود kafkaهستند، توصیه می‌شود که ساختار یا طرح واره اضافی بر محتوای پیام اعمال شود تا به راحتی قابل درک باشد. بسته به نیازهای فردی برنامه شما، گزینه های زیادی برای طرح پیام وجود دارد. استفاده از سیستم‌های ساده‌ای مانند Javascript Object Notation (JSON) و Extensible Markup Language (XML)آسان است و برای انسان قابل خواندن است. با این حال، آنها فاقد ویژگی هایی مانند کنترل نوع قوی و سازگاری بین نسخه های طرحواره هستند. بسیاری از توسعه دهندگان kafka از Apache Avro استفاده می کنند، که یک چارچوب سریال سازی است که در اصل برای Hadoop توسعه یافته است. Avro فرمت سریال سازی فشرده را ارائه می دهد. طرحواره هایی که جدا از payloadپیام هستند و نیازی به ایجاد کد در هنگام تغییر ندارند; و تایپ داده قوی و تکامل Schema، با سازگاری پشتی و جلویی دارند.

یک قالب داده ثابت در kafka مهم است، زیرا اجازه می دهد تا نوشتن و خواندن پیام ها از هم جدا شوند. هنگامی که این وظایف کاملاً همراه هستند، برنامه‌هایی که مشترک پیام‌ها هستند باید به‌روزرسانی شوند تا قالب داده جدید را به موازات قالب قدیمی مدیریت کنند. تنها در این صورت می‌توان برنامه‌هایی را که پیام‌ها را منتشر می‌کنند، برای استفاده از قالب جدید به‌روزرسانی کرد. با استفاده از طرحواره های خوب تعریف شده و ذخیره آنها در یک مخزن مشترک، پیام های kafka را می توان بدون هماهنگی درک کرد.

2-3 پارتیشن‌ها و topicها

پیام‌ها در kafka به topicها دسته‌بندی می‌شوند. نزدیکترین تشابهات برای یک topic یک جدول پایگاه داده یا یک پوشه در یک سیستم فایل است. topicها علاوه بر این، به تعدادی پارتیشن تقسیم می شوند. با بازگشت به توضیحات “Commit log”، یک پارتیشن، یک logتکی است. پیام ها فقط به صورت ضمیمه روی آن نوشته می شوند و از ابتدا تا انتها به ترتیب خوانده می شوند. توجه داشته باشید که از آنجایی که یک topic معمولاً چندین پارتیشن دارد، هیچ تضمینی برای ترتیب زمانی پیام در کل topic، فقط در یک پارتیشن وجود ندارد. شکل 1-5 topic را با چهار پارتیشن نشان می دهد که نوشته هایی به انتهای هر یک اضافه شده است. پارتیشن ها نیز راهی هستند که kafka افزونگی و مقیاس پذیری را فراهم می‌کند. هر پارتیشن را می توان بر روی یک سرور متفاوت میزبانی کرد، به این معنی که یک topic واحد را می توان به صورت افقی در چندین سرور مقیاس بندی کرد تا عملکردی بسیار فراتر از توانایی یک سرور واحد ارائه دهد.

اصطلاح جریان، اغلب هنگام بحث در مورد داده ها در سیستم هایی مانند kafka استفاده می شود. اغلب، یک جریان بدون در نظر گرفتن تعداد پارتیشن ها، یک topicواحد از داده ها در نظر گرفته می شود. این نشان دهنده یک جریان واحد از داده ها است که از تولیدکنندگان به مصرف کنندگان منتقل می شود. این روش ارجاع به پیام‌ها هنگام بحث در مورد پردازش جریان رایج‌تر است، یعنی زمانی که فریم‌ورک‌ها - که برخی از آنها Kafka Streams, Apache Samza, and Storm—operate هستند - روی پیام‌ها به صورد real time کار می‌کنند. این روش عملکرد را می توان با روشی مقایسه کرد که چارچوب های آفلاین، یعنی Hadoop، برای کار بر روی داده های انبوه در آینده طراحی شده اند.

2-4 تولید کننده و مصرف کننده

مشتریان kafka کاربران سیستم هستند و دو نوع اساسی وجود دارد: تولید کنندگان و مصرف کنندگان. همچنین APIهای مشتری پیشرفته وجود دارد - Kafka Connect API برای یکپارچه سازی داده ها و Kafka Streams برای پردازش جریان. مشتریان پیشرفته از تولیدکنندگان و مصرف کنندگان به عنوان بلوک های سازنده استفاده می کنند و عملکرد سطح بالاتری را ارائه می دهند.

تولیدکنندگان پیام‌های جدیدی ایجاد می‌کنند. در سایر سیستم‌های انتشار/اشتراک، ممکن است اینها ناشر یا نویسنده نامیده شوند. به طور کلی، یک پیام برای یک topic خاص تولید می‌شود. به‌طور پیش‌فرض، تولیدکننده اهمیتی نمی‌دهد که یک پیام خاص روی چه پارتیشنی نوشته شده است و پیام‌ها را در تمام پارتیشن‌های یک topicبه طور یکنواخت متعادل می‌کند. در برخی موارد، سازنده پیام‌ها را به پارتیشن‌های خاصی هدایت می‌کند. این کار معمولاً با استفاده از کلید پیام و یک پارتیشن‌کننده انجام می‌شود که یک هش از کلید ایجاد می‌کند و آن را به یک پارتیشن خاص نگاشت می‌کند. این تضمین می‌کند که تمام پیام های تولید شده با یک کلید مشخص در همان پارتیشن نوشته می شوند. تولیدکننده همچنین می‌تواند از یک پارتیشن‌کننده سفارشی استفاده کند که از سایر قوانین تجاری برای نگاشت پیام‌ها به پارتیشن‌ها پیروی می‌کند.

مصرف کنندگان پیام ها را می خوانند. در سایر سیستم های ‌pub/sub، این مشتریان ممکن است subscribers یا readersرا فراخوانی کنند. مصرف کننده در یک یا چند topic مشترک می شود و پیام ها را به ترتیب تولید آنها می خواند. مصرف‌کننده پیام‌هایی را که قبلاً مصرف کرده است، با پیگیری میزان افست پیام‌ها، پیگیری می‌کند.

افست بیت دیگری از فراداده است - یک مقدار صحیح که دائماً افزایش می یابد - که kafka به هر پیامی که تولید میشود اضافه می کند. هر پیام در یک پارتیشن مشخص دارای یک افست منحصر به فرد است. با ذخیره افست آخرین پیام مصرف شده برای هر پارتیشن، چه در Zookeeper یا در خود kafka، یک مصرف کننده می تواند بدون از دست دادن وضعیت خود Stop و restart شود.

مصرف کنندگان به عنوان بخشی از یک گروه مصرف کننده کار می کنند، که یک یا چند مصرف کننده‌ است که با هم کار می کنند تا یک topic را مصرف کنند. گروه اطمینان می دهد که هر پارتیشن فقط توسط یک عضو مصرف می شود. در شکل 1-6، سه مصرف کننده در یک گروه وجود دارند که یک topic را مصرف می کنند. دو نفر از مصرف کنندگان هر کدام از یک پارتیشن کار می کنند، در حالی که مصرف کننده سوم در دو پارتیشن کار می کند. نگاشت مصرف کننده به یک پارتیشن اغلب مالکیت پارتیشن توسط مصرف کننده نامیده می شود.

به این ترتیب، مصرف کنندگان می توانند به صورت افقی برای مصرف topicها تغییر مغیاس دهد. به‌علاوه، اگر یک مصرف‌کننده منفرد شکست بخورد، اعضای باقی‌مانده گروه، پارتیشن‌های مصرف‌شده را مجدداً متعادل می‌کنند تا عضو گمشده را تحویل بگیرند.

2-5 خوشه‌ها و Brokers

به یک سرور kafka، Broker می گویند. کارگزار(Broker) پیام‌هایی را از تولیدکنندگان دریافت می‌کند، افست‌هایی را به آن‌ها اختصاص می‌دهد و پیام‌ها را به ذخیره‌سازی روی دیسک تضمین می‌کند. همچنین به مشتریان سرویس می دهد، به درخواست های واکشی برای پارتیشن‌ها پاسخ می دهد و با پیام هایی که به دیسک اعزام شده اند پاسخ می دهد. بسته به سخت افزار خاص و ویژگی های عملکرد آن، یک کارگزار به راحتی می تواند هزاران پارتیشن و میلیون ها پیام را در ثانیه مدیریت کند.

کارگزاران kafka، طوری طراحی شده اند که به عنوان بخشی از یک خوشه فعالیت کنند. در میان خوشه ای از کارگزاران، یک کارگزار نیز به عنوان کنترل کننده خوشه عمل می کند (به طور خودکار از اعضای live خوشه انتخاب می شود). کنترل کننده مسئول عملیات اداری، از جمله اختصاص پارتیشن به کارگزاران و نظارت بر خرابی کارگزار است. یک پارتیشن، متعلق به یک کارگزار واحد در خوشه است و آن کارگزار رهبر پارتیشن نامیده می شود. ممکن است یک پارتیشن به چندین کارگزار اختصاص داده شود که منجر به تکرار پارتیشن می شود (همانطور که در شکل 1-7 مشاهده می شود). این کار افزونگی پیام‌ها را در پارتیشن فراهم می‌کند، به طوری که در صورت شکست کارگزار، کارگزار دیگری می‌تواند رهبری را بر عهده بگیرد. با این حال، تمام مصرف کنندگان و تولیدکنندگانی که روی آن پارتیشن کار می کنند باید به لیدر متصل شوند.

یکی از ویژگی‌های کلیدی آپاچی kafka، حفظ و نگهداری پیام‌ها برای مدتی طولانی است. کارگزاران kafkaبا یک تنظیم پیش‌فرض برای حفظ topicها پیکربندی شده‌اند، یا پیام‌ها را برای مدتی (مثلاً 7 روز) حفظ می‌کنند یا تا زمانی که topicبه اندازه مشخصی در بایت برسد (مثلاً 1 گیگابایت). پس از رسیدن به این محدودیت‌ها، پیام‌ها منقضی می‌شوند و حذف می‌شوند تا پیکربندی، به منظور حفظ حداقل مقدار داده موجود، در هر زمان باشد. topicهای مجزایی را نیز می توان با تنظیمات نگهداری خاص خود، پیکربندی کرد تا پیام ها تنها تا زمانی که مفید هستند ذخیره شوند. به عنوان مثال، یک topic ردیابی ممکن است برای چند روز حفظ شود، در حالی که متریک برنامه ممکن است فقط برای چند ساعت حفظ شوند. topicات را همچنین می‌توان به صورت فشرده پیکربندی کرد، به این معنی که kafka فقط آخرین پیام تولید شده با یک کلید خاص را حفظ می کند. این می تواند برای داده های متغیر مفید باشد، جایی که فقط آخرین به روز رسانی مورد نظر است.

2-6 خوشه‌های چند گانه

همانطور که استقرار kafka رشد می کند، اغلب داشتن خوشه های متعدد سودمند است. چندین دلیل وجود دارد که چرا این می تواند مفید باشد:

• تفکیک انواع داده ها
• جداسازی برای الزامات امنیتی
• مراکز داده چندگانه (بازیابی خرابی‌ها)

هنگام کار با چندین مرکز داده، اغلب لازم است که پیام ها بین آنها کپی شود. به این ترتیب اپلیکیشن های آنلاین می توانند به فعالیت کاربران در هر دو سایت دسترسی داشته باشند. به عنوان مثال، اگر کاربر اطلاعات عمومی را در نمایه خود تغییر دهد، این تغییر بدون توجه به مرکز داده ای که نتایج جستجو در آن نمایش داده می شود، باید قابل مشاهده باشد. یا، داده های log را می توان از بسیاری از سایت ها در یک مکان مرکزی جمع آوری کرد که در آن سیستم های تجزیه و تحلیل و هشدار میزبانی می شوند. مکانیسم‌های تکثیر در خوشه‌های kafka فقط برای کار در یک خوشه طراحی شده‌اند، نه بین چند خوشه.

پروژه kafka شامل ابزاری به نام MirrorMaker است که برای این منظور استفاده می‌شود. MirrorMaker در هسته خود صرفاً یک مصرف کننده و تولید کننده kafka است که با یک صف به هم مرتبط است. پیام ها از یک خوشه kafka مصرف می شوند و برای خوشه دیگری تولید می شوند. شکل 1-8 نمونه‌ای از معماری را نشان می‌دهد که از MirrorMaker استفاده می‌کند، پیام‌های دو خوشه محلی را در یک خوشه جمع‌آوری می‌کند و سپس آن خوشه را در مراکز داده دیگر کپی می‌کند. ماهیت ساده برنامه قدرت آن را در ایجاد pipeline داده پیچیده،

3 چرا Kafka

انتخاب های زیادی برای سیستم های پیام رسانی انتشار/اشتراک وجود دارد، بنابراین چه چیزی آپاچی kafka را انتخاب خوبی می کند؟

3-1 تولیدکنندگان (producer) متعدد

کافکا قادر است به طور یکپارچه چندین تولید کننده را مدیریت کند، خواه آن مشتریان از topicهای زیادی استفاده می کنند یا از یک topic. این سیستم را برای جمع‌آوری داده‌ها از بسیاری از سیستم‌های frontend و سازگار کردن آن ایده‌آل می‌کند. به عنوان مثال، سایتی که محتوا را از طریق تعدادی میکروسرویس به کاربران ارائه می‌کند، می‌تواند یک topic واحد برای بازدید از صفحه داشته باشد که همه سرویس‌ها می‌توانند با استفاده از یک قالب مشترک در آن بنویسند. سپس برنامه‌های مصرف‌کننده می‌توانند یک جریان از نمایش‌های صفحه را برای همه برنامه‌های موجود در سایت بدون نیاز به هماهنگی مصرف از چندین topic، یکی برای هر برنامه، دریافت کنند.

3-2 مصرف کنندگان ( consumer) متعدد

علاوه بر تولیدکنندگان متعدد، kafka برای چندین مصرف کننده طراحی شده است تا هر جریانی از پیام ها را بدون تداخل با یکدیگر بخوانند. این بر خلاف بسیاری از سیستم‌های صف است که وقتی یک پیام توسط یک مشتری مصرف می‌شود، برای هیچ مشتری دیگری در دسترس نیست. چندین مصرف کننده kafka می توانند انتخاب کنند که به عنوان بخشی از یک گروه فعالیت کنند و یک جریان را به اشتراک بگذارند، و مطمئن شوند که کل گروه یک پیام معین را فقط یک بار پردازش می کند.

3-3 حفظ مبتنی بر دیسک

کافکا نه تنها می تواند چندین مصرف کننده را مدیریت کند، بلکه حفظ پیام بادوام به این معنی است که مصرف کنندگان همیشه نیازی به کار به صورت real time ندارند. پیام ها به دیسک اعزام می‌شوند و با قوانین نگهداری قابل تنظیم ذخیره می‌شوند. این گزینه‌ها را می‌توان بر اساس هر topic انتخاب کرد و به جریان‌های مختلف پیام اجازه می‌دهد بسته به نیاز مصرف‌کننده، مقادیر متفاوتی از نگهداری داشته باشند. نگهداری بادوام به این معنی است که اگر مصرف کننده به دلیل کندی پردازش یا انقباض در ترافیک عقب بماند، خطر از دست دادن داده وجود ندارد. همچنین به این معنی است که تعمیر و نگهداری می‌تواند روی مصرف‌کنندگان انجام شود، برنامه‌ها را برای مدت کوتاهی آفلاین کند، بدون نگرانی در مورد پشتیبان‌گیری پیام‌ها در تولیدکننده یا گم شدن. مصرف کنندگان را می توان متوقف کرد و پیام ها در kafka حفظ خواهند شد. این به آن‌ها اجازه می‌دهد تا پیام‌های پردازشی را از جایی که پایان داده‌اند، مجدداً راه‌اندازی کنند و بدون از دست دادن اطلاعات، آن‌ها را ادامه دهند.

3-4 مقیاس پذیر

انعطاف پذیر بودن مقیاس پذیری در kafka، مدیریت هر مقدار داده را آسان می‌کند. کاربران می‌توانند با یک کارگزار تنها ایده‌ی خود را اثبات و شروع کنند، به یک خوشه توسعه کوچک متشکل از سه کارگزار گسترش دهند و با خوشه ای بزرگتر از ده ها یا حتی صدها کارگزار که در طول زمان با افزایش مقیاس داده ها رشد می کنند، به سمت تولید حرکت کنند. بسط‌ها را می‌توان در زمانی که خوشه آنلاین است انجام داد، بدون اینکه تأثیری بر در دسترس بودن سیستم به‌عنوان یک کل داشته باشد. این همچنین به این معنی است که مجموعه ای از کارگزاران متعدد می توانند با شکست یک کارگزار منفرد مقابله کنند و به خدمات رسانی به مشتریان ادامه دهند. خوشه هایی که نیاز به تحمل خرابی های همزمان بیشتری دارند را می توان با فاکتورهای تکرار بالاتر پیکربندی کرد.

3-5 عملکرد بالا

همه این ویژگی‌ها در کنار هم قرار می‌گیرند تا آپاچی kafkaرا به یک سیستم پیام‌رسانی انتشار/اشتراک با عملکرد عالی در زیر بار بالا تبدیل کند. تولیدکنندگان، مصرف‌کنندگان و کارگزاران همگی می‌توانند به‌راحتی جریان‌های پیامی بسیار بزرگ را مدیریت کنند. این را می توان در حالی انجام داد که هنوز تأخیر پیام دوم را از تولید پیام تا در دسترس بودن برای مصرف کنندگان فراهم می کند.

3-6 اکوسیستم داده

بسیاری از برنامه های کاربردی در محیط هایی که ما برای پردازش داده‌ها می سازیم مشارکت می کنند. ما ورودی‌ها را در قالب برنامه‌هایی تعریف کرده‌ایم که داده‌ها را ایجاد می‌کنند یا به‌طور دیگری آن را به سیستم معرفی می‌کنند. ما خروجی‌ها را در قالب معیارها، گزارش ها و سایر محصولات داده تعریف کرده ایم. ما حلقه‌هایی ایجاد می‌کنیم که برخی از اجزای آن داده‌ها را از سیستم می‌خوانند، آن‌ها را با استفاده از داده‌های منابع دیگر تبدیل می‌کنند و سپس آن را به زیرساخت داده برای استفاده در جاهای دیگر معرفی می‌کنند. این برای انواع مختلفی از داده‌ها انجام می‌شود که هر کدام دارای ویژگی‌های منحصربه‌فردی از محتوا، اندازه و استفاده هستند.

آپاچی kafka سیستم گردش خون را برای اکوسیستم داده فراهم می کند، همانطور که در شکل 1-9 نشان داده شده است. این پیام ها را بین اعضای مختلف زیرساخت حمل می کند و یک رابط ثابت برای همه مشتریان فراهم می کند. هنگامی که با سیستمی برای ارائه طرح‌واره‌های پیام همراه می‌شوند، تولیدکنندگان و مصرف‌کنندگان دیگر نیازی به اتصال محکم یا هر نوع اتصال مستقیم ندارند. هنگامی که موارد تجاری ایجاد و منحل می شوند، می توان مؤلفه ها را اضافه و حذف کرد، و تولیدکنندگان نیازی به نگرانی در مورد اینکه چه کسی از داده ها یا تعداد برنامه های مصرف کننده استفاده می کند، نباشد.

4 موارد کاربرد

4-1 پیگیری فعالیت‌ها

مورد استفاده اصلی kafka، همانطور که در لینکدین طراحی شده است، ردیابی فعالیت کاربر است. کاربران یک وب‌سایت با برنامه‌های فرانت‌اند تعامل دارند، که پیام‌هایی را درباره اقداماتی که کاربر انجام می‌دهد ایجاد می‌کند. این می تواند اطلاعات غیرفعال باشد، مانند بازدید از صفحه و ردیابی کلیک، یا می تواند اقدامات پیچیده تر باشد، مانند اطلاعاتی که کاربر به نمایه خود اضافه می کند. پیام ها در یک یا چند topicمنتشر می شوند، که سپس توسط برنامه های کاربردی در ‌Backend صرف می‌شوند. این برنامه‌ها ممکن است گزارش‌ها را تولید کنند، سیستم‌های یادگیری ماشین را تغذیه کنند، نتایج جستجو را به‌روزرسانی کنند، یا عملیات دیگری را انجام دهند که برای ارائه یک تجربه کاربری غنی لازم است.

4-2 پیام رسانی

کافکا همچنین برای پیام‌رسانی استفاده می‌شود، جایی که برنامه‌ها باید اعلان‌هایی (مانند ایمیل‌ها) را برای کاربران ارسال کنند. این برنامه‌ها می‌توانند پیام‌ها را بدون نیاز به نگرانی در مورد قالب‌بندی یا نحوه ارسال پیام‌ها تولید کنند. سپس یک برنامه واحد می‌تواند تمام پیام‌های ارسالی را بخواند و آنها را به طور مداوم مدیریت کند، از جمله:

· قالب بندی پیام ها (همچنین به عنوان تزئین شناخته می شود) با استفاده از ظاهر و احساس مشترک

· جمع آوری چندین پیام در یک اعلان برای ارسال

· اعمال تنظیمات مورد نظر کاربر برای نحوه دریافت پیام

استفاده از یک برنامه کاربردی برای این کار از نیاز به تکرار عملکرد در برنامه‌های چندگانه جلوگیری می‌کند و همچنین امکان عملیاتی مانند تجمیع را فراهم می‌کند که در غیر این صورت ممکن نیست.

4-3 متریک و ثبت گزارش

کافکا همچنین برای جمع‌آوری متریک‌های برنامه و سیستم و گزارش‌ها ایده‌آل است. این یک مورد استفاده است که در آن توانایی داشتن چندین برنامه کاربردی که همان نوع پیام را تولید می کنند می درخشد. برنامه ها معیارها را به طور منظم برای یک topic kafka منتشر می کنند، و این معیارها می توانند توسط سیستم هایی برای نظارت و هشدار مصرف شوند. آنها همچنین می توانند در یک سیستم آفلاین مانند Hadoopبرای انجام تجزیه و تحلیل طولانی مدت، مانند پیش بینی رشد، استفاده شوند. پیام‌های گزارش را می‌توان به همین روش منتشر کرد و می‌توان آن‌ها را به سیستم‌های جستجوی گزارش اختصاصی مانند Elastisearch یا برنامه‌های تحلیل امنیتی هدایت کرد. یکی دیگر از مزایای اضافه شده kafka این است که زمانی که سیستم مقصد نیاز به تغییر دارد (به عنوان مثال، زمان به روز رسانی سیستم ذخیره سازی گزارش است)، نیازی به تغییر برنامه های frontend یا ابزارهای تجمیع وجود ندارد.

4-4 اعزام لاگ

از آنجایی که kafka بر اساس مفهوم commit log است، تغییرات پایگاه داده را می‌توان در kafka منتشر کرد و برنامه‌ها می‌توانند به راحتی این جریان را برای دریافت به‌روزرسانی‌های live در صورت وقوع، کنترل کنند. این جریان تغییرات همچنین می‌تواند برای تکرار به‌روزرسانی‌های پایگاه داده به یک سیستم راه دور یا برای ادغام تغییرات از چندین برنامه در یک نمای پایگاه داده واحد استفاده شود. ماندگاری بادوام در اینجا برای تهیه بافری برای تغییرات لاگ مفید است، به این معنی که در صورت خرابی برنامه‌های مصرف‌کننده می‌توان آن را دوباره پخش کرد. متناوباً، topicهای فشرده‌شده با گزارش را می‌توان برای حفظ ماندگاری طولانی‌تر تنها با حفظ یک تغییر در هر کلید استفاده کرد.

4-5 پردازش جریان

حوزه دیگری که انواع متعددی از برنامه ها را ارائه می دهد، پردازش جریان است. در حالی که تقریباً تمام استفاده از kafka را می‌توان به عنوان پردازش جریانی در نظر گرفت، این اصطلاح معمولاً برای اشاره به برنامه‌هایی استفاده می‌شود که عملکردی مشابه برای نقشه/کاهش پردازش در Hadoop ارائه می‌دهند. Hadoop معمولاً متکی به جمع آوری داده ها در یک بازه زمانی طولانی، چه ساعت ها و چه روزها است. پردازش جریانی بر روی داده‌ها در زمان واقعی عمل می کند، به همان سرعتی که پیام ها تولید می شوند. چارچوب‌های جریان به کاربران اجازه می‌دهند برنامه‌های کوچکی بنویسند تا بر روی پیام‌های kafka کار کنند، کارهایی مانند شمارش متریک‌ها، تقسیم‌بندی پیام‌ها برای پردازش کارآمد توسط برنامه‌های کاربردی دیگر، یا تبدیل پیام‌ها با استفاده از داده‌های چند منبع.

5 اصالت وجودی kafka

کافکا برای رفع مشکل pipelineداده در لینکدین ایجاد شد. این سیستم به منظور ارائه یک سیستم پیام رسانی با کارایی بالا طراحی شده است که می تواند انواع مختلفی از داده ها را مدیریت کند و داده های تمیز و ساختار یافته در مورد فعالیت کاربر و معیارهای سیستم را به صورت real time ارائه دهد.

Data really powers everything that we do.

—Jeff Weiner, CEO of LinkedIn

5-1 مسئله‌ي لینکدین

مشابه مثالی که در ابتدای این فصل توضیح داده شد، لینکدین دارای سیستمی برای جمع‌آوری متریک‌های سیستم و برنامه بود که از جمع‌آورنده‌های سفارشی و ابزارهای منبع باز برای ذخیره و ارائه داده‌ها به صورت داخلی استفاده می‌کرد. علاوه بر متریک‌های سنتی، مانند استفاده از CPU و عملکرد برنامه، یک ویژگی پیچیده ردیابی درخواست وجود داشت که از سیستم نظارت استفاده می‌کرد و می‌توانست نگاهی به نحوه انتشار یک درخواست کاربر از طریق برنامه‌های داخلی داشته باشد. با این حال، سیستم نظارت ایرادات زیادی داشت. این شامل مجموعه متریک‌ها بر اساس نظرسنجی، فواصل زیاد بین معیارها، و عدم توانایی صاحبان برنامه برای مدیریت معیارهای خود بود. این سیستم بسیار لمسی بود، نیاز به مداخله انسانی برای اکثر کارهای ساده داشت، و ناسازگار بود، با نام‌های متریک متفاوت برای اندازه‌گیری یکسان در سیستم‌های مختلف.

در همان زمان، سیستمی برای ردیابی اطلاعات فعالیت کاربر ایجاد شد. این یک سرویس HTTP بود که سرورهای frontend به صورت دوره ای به آن متصل می شدند و دسته ای از پیام ها را (در قالب XML) به سرویس HTTP منتشر می کردند. سپس این دسته‌ها به پردازش آفلاین منتقل شدند، جایی که فایل‌ها تجزیه و جمع‌آوری شدند. این سیستم ایرادات زیادی داشت. قالب بندی XML ناسازگار بود و تجزیه آن از نظر محاسباتی گران بود. تغییر نوع فعالیت کاربر که ردیابی می‌شد به مقدار قابل توجهی کار هماهنگ بین فرانت‌اندها و پردازش آفلاین نیاز داشت. حتی در آن زمان، سیستم به دلیل تغییر طرحواره ها دائماً خراب می شود. ردیابی بر اساس دسته‌بندی ساعتی ساخته شده بود، بنابراین نمی‌توان از آن به صورت real time استفاده کرد.

نظارت و ردیابی فعالیت کاربر نمی تواند از یک سرویس backendاستفاده کند. سرویس مانیتورینگ خیلی بد بود، قالب داده برای ردیابی فعالیت جهت‌گیری نشده بود، و مدل نظرسنجی برای نظارت با مدل فشار برای ردیابی سازگار نبود. در همان زمان، سرویس ردیابی برای استفاده از معیارها بسیار شکننده بود و پردازش دسته‌گرا مدل مناسبی برای نظارت و هشدار به صورت real time نبود. با این حال، داده‌های نظارت و ردیابی ویژگی‌های بسیاری را به اشتراک می‌گذاشتند، و همبستگی اطلاعات (مانند اینکه چگونه انواع خاصی از فعالیت کاربر بر عملکرد برنامه تأثیر می‌گذارد) بسیار مطلوب بود. کاهش در انواع خاصی از فعالیت کاربر می‌تواند نشان‌دهنده مشکلات برنامه‌ای باشد که به آن سرویس می‌دهد، اما ساعت‌ها تاخیر در پردازش دسته‌های فعالیت به معنای پاسخ آهسته به این نوع مسائل است.

در ابتدا، راه‌حل‌های منبع باز موجود به‌طور کامل مورد بررسی قرار گرفتند تا سیستم جدیدی پیدا شود که دسترسی بلادرنگ به داده‌ها و مقیاس‌بندی برای مدیریت میزان ترافیک پیام مورد نیاز را فراهم کند. سیستم های نمونه اولیه با استفاده از ActiveMQ راه اندازی شدند، اما در آن زمان نمی توانست مقیاس را مدیریت کند. همچنین یک راه حل شکننده برای روشی بود که LinkedIn برای استفاده از آن نیاز داشت، کشف نقص‌های زیادی در ActiveMQکه باعث توقف brokerها می‌شد. این امر از اتصالات به مشتریان، نسخه پشتیبان تهیه می کند و در توانایی برنامه ها برای ارائه درخواست ها به کاربران تداخل ایجاد می کند. تصمیم به پیشبرد زیرساخت سفارشی برای pipelineداده گرفته شد.

5-2 تولد kafka

تیم توسعه در LinkedIn توسط Jay Kreps، یک مهندس نرم‌افزار اصلی که قبلاً مسئول توسعه و انتشار منبع باز Voldemort بود، یک سیستم ذخیره‌سازی با ارزش کلیدی توزیع شده، رهبری می‌شد. تیم اولیه نیز شاملNeha Narkhede و بعداً Jun Rao بود. آنها با هم شروع به ایجاد یک سیستم پیام رسانی کردند که بتواند نیازهای سیستم های نظارت و ردیابی را برآورده کند و برای آینده مقیاس کند. اهداف اولیه عبارت بودند از:

تولیدکنندگان و مصرف کنندگان را با استفاده از مدل push-pull جدا کنید

پایداری برای داده های پیام در سیستم پیام رسانی برای اجازه دادن به مصرف کنندگان متعدد فراهم کنید

برای خروجی بالای پیام ها بهینه سازی کنید

اجازه برای رشد مقیاس افقی سیستم با رشد جریان های داده

نتیجه یک سیستم پیام‌رسانی انتشار/اشتراک بود که یک رابط معمولی برای سیستم‌های پیام‌رسانی داشت اما یک لایه ذخیره‌سازی بیشتر شبیه یک سیستم log-agregation بود. همراه با پذیرش Apache Avro برای سریال‌سازی پیام، kafka برای مدیریت معیارها و ردیابی فعالیت کاربر در مقیاس میلیاردها پیام در روز مؤثر بود. مقیاس پذیری kafka به استفاده از لینکدین کمک کرده است که بیش از یک تریلیون پیام تولید شده (تا اوت 2015) و بیش از یک پتابایت داده مصرف شده روزانه افزایش یابد.

5-3 منبع باز

کافکا به عنوان یک پروژه منبع باز در GitHub در اواخر سال 2010 منتشر شد. با توجه به جلب توجه در جامعه منبع باز، در جولای 2011 به عنوان یک پروژه انکوباتور بنیاد نرم افزار آپاچی پیشنهاد و پذیرفته شد. آپاچی kafka از انکوباتور در سال 2011 فارغ التحصیل شد. اکتبر 2012. از آن زمان، به طور مداوم روی آن کار شده است و جامعه قوی از مشارکت کنندگان و متعهدین خارج از لینکدین پیدا کرده است. kafka اکنون در برخی از بزرگترین خطوط لوله داده در جهان استفاده می شود. در پاییز 2014، Jay Kreps, Neha Narkhede, و Jun Raoلینکدین را ترک کردند تا Confluentرا تأسیس کنند، شرکتی که حول محور ارائه توسعه، پشتیبانی سازمانی و آموزش برای آپاچی kafka است. این دو شرکت، همراه با مشارکت‌های رو به رشد دیگران در جامعه منبع باز، به توسعه و حفظ kafka ادامه می‌دهند و آن را به اولین انتخاب برای خطوط لوله داده‌های بزرگ تبدیل می‌کنند.

5-4 نام گذاری

نام

مردم اغلب می پرسند که نام kafka چگونه بوده و آیا ربطی به خود برنامه دارد یا خیر. جی کرپس بینش زیر را ارائه کرد:

فکر می‌کردم از آنجایی که kafka یک سیستم بهینه‌سازی شده برای نوشتن است، استفاده از نام نویسنده منطقی است. من در کالج در کلاس های ادبی زیاد شرکت کرده بودم و فرانتس kafka را دوست داشتم. به علاوه این نام برای یک پروژه منبع باز جالب به نظر می رسید.

بنابراین اساساً رابطه زیادی وجود ندارد.

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است