22 سبتمبر 2025·8 دقيقة
ما هو كافكا وكيف يُستخدم في الأنظمة الحديثة؟
تعرف على Apache Kafka وكيفية عمل المواضيع والأقسام، وأين يناسب كافكا الأنظمة الحديثة لنقل الأحداث في الوقت الحقيقي، والسجلات، وأنابيب البيانات.
تعرف على Apache Kafka وكيفية عمل المواضيع والأقسام، وأين يناسب كافكا الأنظمة الحديثة لنقل الأحداث في الوقت الحقيقي، والسجلات، وأنابيب البيانات.
Apache Kafka هي منصة توزيع لتدفق الأحداث (distributed event streaming platform). ببساطة، هي "أنبوب" مشترك ودائم يسمح للعديد من الأنظمة بنشر حقائق حول ما حدث ويتيح لأنظمة أخرى قراءة تلك الحقائق—بسرعة، بمقياس كبير، وبترتيب.
تستخدم الفرق كافكا عندما تحتاج البيانات إلى الانتقال بشكل موثوق بين الأنظمة دون ارتباط وثيق. بدل أن يستدعي تطبيقٌ واحد تطبيقًا آخر مباشرةً (ويفشل حينما يكون ذلك التطبيق متوقفًا أو بطيئًا)، يكتب المنتجون أحداثًا إلى كافكا. يقرأها المستهلكون عندما يكونون جاهزين. يخزن كافكا الأحداث لفترة قابلة للتهيئة، لذا يمكن للأنظمة التعافي من الانقطاعات وحتى إعادة معالجة التاريخ.
هذا الدليل موجه للمهندسين المهتمين بالمنتج، وفِرق البيانات، والقادة الفنيين الذين يريدون نموذجًا ذهنيًا عمليًا لكافكا.
ستتعلم اللبنات الأساسية (المنتجون، المستهلكون، المواضيع، الوسطاء)، كيف يتوسع كافكا بالأقسام، كيف يخزن ويعيد تشغيل الأحداث، وأين يناسب في المعمارية المدفوعة بالأحداث. سنغطي أيضًا حالات الاستخدام الشائعة، ضمانات التسليم، أساسيات الأمان، تخطيط التشغيل، ومتى يكون كافكا (أو ليس) الأداة المناسبة.
أسهل طريقة لفهم كافكا هي كونه سجلًا مشتركًا للأحداث: التطبيقات تكتب أحداثًا إليه، وتقرأ تطبيقات أخرى تلك الأحداث لاحقًا—غالبًا في الوقت الحقيقي، وأحيانًا بعد ساعات أو أيام.
المنتجون هم الكتّاب. قد ينشر المنتج حدثًا مثل "تم إنشاء طلب"، "تأكيد الدفع"، أو "قراءة درجة الحرارة". لا يرسِل المنتجون الأحداث مباشرةً إلى تطبيقات محددة—بل يرسلونها إلى كافكا.
المستهلكون هم القرّاء. قد يغذي المستهلك لوحة تحكم، أو يحفز سير عمل شحن، أو يحمل البيانات إلى التحليلات. يقرر المستهلكون ما يفعلون بالأحداث، ويمكنهم القراءة بوتيرتهم الخاصة.
تُجمَّع الأحداث في كافكا ضمن مواضيع، التي هي فئات مسماة. على سبيل المثال:
orders لأحداث متعلقة بالطلباتpayments لأحداث الدفعinventory لتغييرات المخزونيصبح الموضوع تيار "مصدر الحقيقة" لذلك النوع من الأحداث، مما يسهل على فرق متعددة إعادة استخدام نفس البيانات دون بناء تكاملات مخصصة.
الوسيط هو خادم كافكا يخزن الأحداث ويخدمها للمستهلكين. عمليًا، يعمل كافكا كـ عنقود (عدة وسطاء معًا) ليتمكن من التعامل مع حركة أكبر ويظل يعمل حتى إن تعطل جهاز.
غالبًا ما تعمل المستهلكات ضمن مجموعة مستهلكين. يوزع كافكا عبء القراءة عبر المجموعة، لذا يمكنك إضافة مثيلات مستهلكة أكثر لتوسيع المعالجة بالتوازي—دون أن تقوم كل مثيلة بنفس العمل.
يتوسع كافكا عن طريق تقسيم العمل إلى مواضيع (تدفقات من الأحداث ذات صلة) ثم تقسيم كل موضوع إلى أقسام (partitions) هي شرائح أصغر ومستقلة من ذلك التيار.
الموضوع الذي يحتوي قسمًا واحدًا يمكن قراءته من قِبل مستهلك واحد فقط في كل مرة داخل مجموعة مستهلكين. أضف أقسامًا، ويمكنك إضافة مستهلكين لمعالجة الأحداث بشكل متوازي. هكذا يدعم كافكا تدفق الأحداث عالي الحجم وأنابيب البيانات في الزمن الحقيقي دون جعل كل نظام نقطة اختناق.
تساعد الأقسام أيضًا في توزيع الحمل عبر الوسطاء. بدل أن يتعامل جهاز واحد مع كل الكتابات والقراءات لموضوع ما، يمكن لوسطاء متعددين استضافة أقسام مختلفة ومشاركة الحركة.
يكفل كافكا الترتيب داخل القسم الواحد. إذا كُتِبت الأحداث A وB وC إلى نفس القسم بهذا الترتيب، فسوف يقرؤها المستهلكون A → B → C.
لا يضمن الترتيب عبر الأقسام. إذا احتجت ترتيبًا صارمًا لكيان محدد (مثل عميل أو طلب)، عادةً ما تتأكد من أن جميع أحداث ذلك الكيان تذهب إلى نفس القسم.
عندما يرسل المنتج حدثًا، يمكنه تضمين مفتاح (مثل order_id). يستخدم كافكا المفتاح لتوجيه الأحداث ذات الصلة باستمرار إلى نفس القسم. هذا يمنحك ترتيبًا متوقعًا لذلك المفتاح مع السماح للموضوع نفسه بأن يتوسع عبر أقسام متعددة.
يمكن أن يُستنسخ كل قسم إلى وسطاء آخرين. إذا تعطل وسيطٌ واحد، يمكن لنسخة مطابقة أن تتولى المهمة. النسخ سبب رئيسي لثقة الفرق في كافكا للرسائل من نوع نشر-اشتراك (pub-sub) والأنظمة المدفوعة بالأحداث: فهو يحسن التوفر ويدعم التحمل للأخطاء دون أن يحتاج كل تطبيق إلى منطق استرداد خاص به.
فكرة رئيسية في Apache Kafka هي أن الأحداث لا تُمرَّر وتُنسى. تُكتب على القرص في سجل مرتب، لذا يمكن للمستهلكين قراءتها الآن—أو لاحقًا. هذا يجعل كافكا مفيدًا ليس فقط لنقل البيانات، بل أيضًا للحفاظ على تاريخ دائم لما حدث.
عندما يرسل المنتج حدثًا إلى موضوع، يلحقه كافكا بالتخزين على الوسيط. ثم يقرأ المستهلكون من ذلك السجل المخزن بوتيرتهم. إذا توقف مستهلك لساعة، تبقى الأحداث ويمكن اللحاق بها عند استعادته.
يحتفظ كافكا بالأحداث وفق سياسات الاحتفاظ:
يُضبط الاحتفاظ لكل موضوع، مما يتيح لك معاملة "موضوعات سجل المراجعة" بشكل مختلف عن موضوعات القياس عالية الحجم.
بعض المواضيع أشبه بسجل تغييرات أكثر من أرشيف تاريخي—مثل "إعدادات العميل الحالية". يحافظ الضغط اللوغاريتمي على أحدث حدث على الأقل لكل مفتاح، بينما قد تُزال السجلات القديمة المتجاوزة. تظل لديك بذلك مصدر دائم للحقيقة لأحدث الحالة، من دون نمو غير محدود للسجل.
بسبب بقاء الأحداث مخزنة، يمكنك إعادة تشغيلها لإعادة بناء الحالة:
في الممارسة، تُتحكَّم عملية إعادة التشغيل بمكان "بدء القراءة" للمستهلك (إزاحته)، مما يمنح الفرق شبكة أمان قوية عند تطور الأنظمة.
كافكا مبني ليحافظ على تدفق البيانات حتى عند فشل أجزاء من النظام. يحقق ذلك عبر النسخ، قواعد واضحة عن من "الزعيم" لكل قسم، وتأكيدات كتابة قابلة للتهيئة.
لكل قسم في الموضوع زعيم (leader) وواحد أو أكثر من النسخ التابعة (followers) على وسطاء آخرين. يتحدث المنتجون والمستهلكون إلى الزعيم لذلك القسم.
النسخ تتابع نسخ بيانات الزعيم. إذا توقف الزعيم، يستطيع كافكا ترقية تابع متزامن إلى زعيم جديد، فتبقى القسم متاحًا.
إذا تعطل وسيط، تصبح الأقسام التي كان يملكها كزعماء غير متاحة لحظة. يكشف المتحكم في كافكا عن الفشل ويشغّل انتخاب زعيم جديد لتلك الأقسام.
إذا كان هناك تابع واحد على الأقل محدث بما فيه الكفاية، يمكنه تولي القيادة ويستأنف العملاء الإنتاج/الاستهلاك. إذا لم يتوفر تابع متزامن، قد يوقف كافكا الكتابات (حسب الإعدادات) لتفادي فقدان بيانات تم تأكيدها بالفعل.
مؤشران رئيسيان يشكلان الديمومة:
على مستوى مفاهيمي:
لتقليل التكرارات أثناء إعادة المحاولة، غالبًا ما تربط الفرق إعدادات تأكيد أكثر أمانًا بمنتجين قابلين للحذف (idempotent) ومعالجة مستهلك قوية.
الأمان الأعلى يعني عادةً الانتظار لمزيد من التأكيدات والمحافظة على نسخ أكثر متزامنة، مما قد يزيد الكمون ويقلل أقصى إنتاجية.
إعدادات الكمون المنخفضة قد تكون مقبولة لبيانات القياس أو تدفقات النقرات حيث يمكن قبول فقدان عرضي، بينما المدفوعات والمخزون وسجلات المراجعة عادةً ما تبرّر الأمان الزائد.
المعماريات المدفوعة بالأحداث تبني الأنظمة بحيث تمثل الأحداث الأعمال التي تجري—طلب تم إنشاؤه، دفع مُؤكَّد، طرد شحن—كـ أحداث يمكن لأجزاء أخرى من النظام أن تتفاعل معها.
كافكا غالبًا ما يجلس في مركز EDA كتدفق أحداث مشترك. بدل أن تستدعي الخدمة A الخدمة B مباشرة، تنشر الخدمة A حدثًا (مثل OrderCreated) إلى موضوع كافكا. يمكن لأي عدد من الخدمات الأخرى استهلاك الحدث واتخاذ إجراء—إرسال بريد، حجز مخزون، تشغيل فحص احتيال—دون أن تحتاج الخدمة A أن تعرف بوجودهم.
بما أن الخدمات تتواصل عبر الأحداث، لا تضطر إلى التنسيق عبر واجهات طلب/استجابة لكل تفاعل. هذا يقلل الاعتماد الوثيق بين الفرق ويسهل إضافة ميزات جديدة: يمكنك إدخال مستهلك جديد لحدث موجود دون تغيير المنتج.
EDA بطبيعته غير متزامن: يكتب المنتجون الأحداث بسرعة، ويعالجها المستهلكون بوتيرتهم. أثناء الارتفاعات المفاجئة في الحركة، يساعد كافكا في امتصاص الزحمة كوسادة حتى لا تنهار الأنظمة المتدنية فورًا. يمكن للمستهلكين التوسع لمواكبة، وإذا تعطل مستهلك مؤقتًا، يمكنه المتابعة من حيث انتهى.
فكر في كافكا كـ "تغذية نشاط" للنظام. ينشر المنتجون حقائق؛ يشترك المستهلكون في الحقائق التي يهتمون بها. هذا النمط يمكّن أنابيب بيانات في الزمن الحقيقي وسير عمل مدفوع بالأحداث مع الحفاظ على خدمات أبسط وأكثر استقلالية.
يظهر كافكا حيث تحتاج الفرق إلى نقل الكثير من "الحقائق الصغيرة التي حدثت" بين الأنظمة—بسرعة، وبشكل موثوق، وبطريقة يمكن لعدة مستهلكين إعادة استخدامها.
تحتاج التطبيقات غالبًا إلى تاريخ قابل للإلحاق: تسجيلات تسجيل الدخول، تغييرات الأذونات، تحديثات السجلات، أو إجراءات المشرف. يعمل كافكا جيدًا كتيار مركزي لهذه الأحداث، بحيث تقرأ أدوات الأمان والتقارير والتصديرات الامتثالية نفس المصدر دون تحميل قاعدة البيانات الإنتاجية. وبما أن الأحداث محفوظة لفترة، يمكنك أيضًا إعادة تشغيلها لإعادة بناء وجهة مراجعة بعد خطأ أو تغيير في المخطط.
بدل أن تستدعي الخدمات بعضها بعضًا، يمكنها نشر أحداث مثل "order created" أو "payment received". تشترك خدمات أخرى وتتفاعل في وقتها الخاص. هذا يقلل الترابط الوثيق، يساعد الأنظمة على الاستمرار أثناء أعطال جزئية، ويسهل إضافة قدرات جديدة (مثل فحوصات الاحتيال) ببساطة عن طريق استهلاك تيار الأحداث الموجود.
كافكا شائع كعمود فقري لنقل البيانات من أنظمة التشغيل إلى منصات التحليلات. يمكن للفرق تدفق التغييرات من قواعد بيانات التطبيقات وتسليمها إلى مخزن البيانات أو البحيرة بزمن تأخير منخفض، مع إبقاء التطبيق الإنتاجي منفصلًا عن استعلامات التحليل الثقيلة.
تأتي بيانات الحساسات والأجهزة وقياسات التطبيقات غالبًا على شكل دفعات. يمكن لكافكا امتصاص الاندفاعات، وتخزينها مؤقتًا بأمان، وترك المعالجة التالية للحاق بالركب—مفيد للمراقبة والتنبيه والتحليل الطويل الأمد.
كافكا أكثر من وسطاء ومواضيع. تعتمد معظم الفرق على أدوات مصاحبة تجعل كافكا عمليًا لحركة البيانات اليومية، ومعالجة التدفقات، والتشغيل.
Kafka Connect هو إطار عمل التكامل لكافكا لجلب البيانات إلى كافكا (مصادر) ومن كافكا (مصارف). بدل بناء وصيانة أنابيب مخصصة، تشغّل Connect وتكوّن الموصلات.
أمثلة شائعة تشمل سحب التغييرات من قواعد البيانات، استيراد أحداث SaaS، أو تسليم بيانات كافكا إلى مستودع بيانات أو تخزين كائنات. كما يوحِّد Connect اعتبارات التشغيل مثل إعادة المحاولة والإزاحات والتوازي.
إذا كان Connect للتكامل، فـ Kafka Streams هو للحساب. إنها مكتبة تضيفها إلى تطبيقك لتحويل التدفقات في الزمن الحقيقي—تصفية الأحداث، إثراؤها، انضمام التدفقات، وبناء التجميعات (مثل "الطلبات لكل دقيقة").
بما أن تطبيقات Streams تقرأ من المواضيع وتكتب إليها، فإنها تتناسب طبيعيًا مع الأنظمة المدفوعة بالأحداث ويمكنها التوسع بإضافة مثيلات أكثر.
مع نشر فرق متعددة للأحداث، يصبح الاتساق مهمًا. تساعد إدارة المخططات (غالبًا عبر سجل مخططات) في تعريف الحقول التي يجب أن يحتويها الحدث وكيفية تطورها بمرور الوقت. هذا يمنع كسر المستهلكين حين يغير المنتج حقلًا يعتمدون عليه.
كافكا حساس تشغيليًا، لذا المراقبة الأساسية ضرورية:
تستخدم معظم الفرق أيضًا واجهات إدارة وأتمتة للنشر، وتكوين المواضيع، وسياسات التحكم بالوصول (راجع /blog/kafka-security-governance).
غالبًا ما يُوصف كافكا بأنه "سجل دائم + مستهلكون"، لكن ما تهتم به الفرق في الواقع هو: هل سأعالج كل حدث مرة واحدة فقط، وماذا يحدث عند الفشل؟ يقدم كافكا أدوات بناء، وأنت تختار المفاضلات.
حد أقصى مرة واحدة (at-most-once) يعني قد تفقد أحداثًا، لكن لن تُعالج مكررات. قد يحدث هذا إذا أبلغ المستهلك عن موضعه أولًا ثم تعطل قبل إكمال العمل.
على الأقل مرة واحدة (at-least-once) يعني لن تفقد أحداثًا، لكن التكرارات ممكنة (مثال: يعالج المستهلك حدثًا، يتعطل، ثم يعالجه مرة أخرى بعد إعادة التشغيل). هذا هو النمط الشائع الافتراضي.
مرة واحدة بالضبط (exactly-once) تهدف لتفادي كل من الفقدان والتكرار عبر نهاية المسار. في كافكا، يتضمن ذلك عادة منتجين معاملاتيين ومعالجة متوافقة (غالبًا عبر Kafka Streams). إنه قوي، لكنه أكثر تقييدًا ويتطلب إعدادًا دقيقًا.
في الممارسة، تتبنّى العديد من الأنظمة نمط at-least-once وتضيف احتياطات:
الإزاحة هي موضع آخر سجل مُعالَج في القسم. عند تأكيد الإزاحات، تقول "أنهيت حتى هنا". أكد مبكرًا وتخاطر بالخسارة؛ أكد متأخرًا وتزيد التكرارات بعد الفشل.
يجب أن تكون إعادة المحاولة محدودة وواضحة. نمط شائع:
هذا يمنع رسالة "سامة" واحدة من حجب مجموعة المستهلكين بأكملها مع الحفاظ على البيانات لإصلاحها لاحقًا.
كافكا غالبًا ما يحمل أحداثًا حرجة للأعمال (طلبات، مدفوعات، نشاط المستخدم). هذا يجعل الأمان والحوكمة جزءًا من التصميم، وليس فكرة لاحقة.
المصادقة تجيب عن "من أنت؟" والتفويض عن "ما الذي يسمح لك به؟" في كافكا، تُجرى المصادقة عادةً عبر SASL (مثال: SCRAM أو Kerberos)، بينما يُنفَّذ التفويض عبر قوائم التحكم بالوصول (ACLs) على مستوى الموضوع، مجموعة المستهلكين، والعنقود.
نمط عملي: مبدأ الأقل امتياز—يسمح للمنتجين بالكتابة فقط إلى المواضيع التي يملكونها، ويمكن للمستهلكين القراءة فقط من المواضيع التي يحتاجونها. هذا يقلل من التعرض العرضي للبيانات ويحد من مدى الضرر إذا تسربت بيانات الاعتماد.
TLS يشفر البيانات أثناء انتقالها بين التطبيقات والوسطاء والأدوات. بدونه، قد تُعترض الأحداث داخل الشبكات الداخلية وليس فقط على الإنترنت العام. كما يساعد TLS في منع هجمات الوسيط (MITM) عن طريق التحقق من هوية الوسطاء.
عندما تشارك فرق متعددة عنقودًا واحدًا، تصبح الضوابط مهمة. تسهّل اتفاقيات تسمية الموضوعات الواضحة (مثال: <team>.<domain>.<event>.<version>) معرفة الملكية وتطبيق السياسات تلقائيًا.
اقترن التسمية هذه بنسب استخدام وقوالب ACL حتى لا يستنزف حمولة مزعجة الموارد الأخرى، ولكي تبدأ الخدمات الجديدة بإعدادات آمنة افتراضية.
عامل كافكا كنظام سجل للأحداث فقط عندما تنوي ذلك. إذا كانت الأحداث تتضمن بيانات شخصية (PII)، استخدم تقليل البيانات (أرسل معرّفات بدل الملفات الشخصية كاملة)، وفكر في التشفير على مستوى الحقول، ووثّق الموضوعات الحساسة.
يجب أن تتوافق إعدادات الاحتفاظ مع المتطلبات القانونية والتجارية. إذا تنص السياسة على "الحذف بعد 30 يومًا" فلا تحتفظ بستة أشهر "لمجرد الاحتياط". المراجعات الدورية والتدقيقات تبقي التكوينات متوافقة مع تطور الأنظمة.
تشغيل Apache Kafka ليس "نصّب وانسَ". يتصرف أكثر كمرفق مشارك: تعتمد عليه فرق عديدة، وزلات صغيرة قد ينتشر أثرها إلى التطبيقات اللاحقة.
سعة كافكا مسألة حسابية تعيد النظر فيها بانتظام. الروافع الأكبر هي الأقسام (التوازي)، ومعدل النقل (MB/s الداخل والخارج)، ونمو التخزين (مدة الاحتفاظ).
إذا تضاعفت الحركة، قد تحتاج إلى أقسام أكثر لتوزيع الحمل عبر الوسطاء، وقرص أكثر للاحتفاظ، وعرض نطاق شبكي أكبر للنسخ. عادةً ما تتوقع فرق عملية: تقدّر ذروة معدل الكتابة وتضربها بوقت الاحتفاظ لتقدير نمو القرص، ثم تضيف هامشًا للنسخ و"نجاح غير متوقع".
توقّع عملًا روتينيًا أكثر من مجرد الحفاظ على الخوادم:
التكلفة تأتي من الأقراص، مخرجات الشبكة، وعدد/حجم الوسطاء. يمكن للخدمة المُدارة أن تقلل عبء الموظفين وتبسط التحديثات، بينما قد يكون الاستضافة الذاتية أرخص على المدى البعيد إذا كان لديك مشغّلون ذوو خبرة. المقايضة هنا هي زمن الاستعادة والعبء على فريق الاستجابة.
غالبًا ما تراقب الفرق:
لوحات تحكم جيدة وتنبيهات دقيقة تحول كافكا من "صندوق غامض" إلى خدمة مفهومة.
كافكا مناسب عندما تحتاج إلى نقل كثير من الأحداث بشكل موثوق، والاحتفاظ بها لفترة، وترك أنظمة متعددة تتفاعل مع نفس البيانات بوتيرتها. هو مفيد بشكل خاص عندما يجب أن تكون البيانات قابلة لإعادة التشغيل (للتراجع، المراجعات، أو إعادة بناء خدمة) وعندما تتوقع إضافة منتجين/مستهلكين بمرور الوقت.
يتألق كافكا عندما يكون لديك:
قد يكون كافكا أكثر من اللازم إذا كانت احتياجاتك بسيطة:
في هذه الحالات، قد يفوق عبء التشغيل (حجم العنقود، التحديثات، المراقبة، الاستدعاء الطارئ) الفائدة.
كافكا يكمل—لا يستبدل—قواعد البيانات (نظام السجل)، الذاكرات المخبئية (قراءات سريعة)، وأدوات ETL الدُفعيّة (تحويلات دورية كبيرة).
اسأل نفسك:
إذا كانت غالبية الإجابات "نعم"، فغالبًا ما يكون كافكا خيارًا معقولًا.
يناسب كافكا أفضل عندما تحتاج مصدر "مصدر الحقيقة" مشتركًا لتدفقات الأحداث في الزمن الحقيقي: أنظمة عديدة تنتج حقائق (طلبات أنشئت، دفعات مُصرَّح بها، تغييرات المخزون) وأنظمة عديدة تستهلك تلك الحقائق لتشغيل الأنابيب، التحليلات، والميزات التفاعلية.
ابدأ بتدفق ضيق ذي قيمة عالية—مثل نشر أحداث "OrderPlaced" للخدمات اللاحقة (البريد، فحوص الاحتيال، الت fulfilment). تجنّب جعل كافكا قائمة شاملة من اليوم الأول.
اكتب:
حافظ على المخططات الأولية بسيطة ومتناسقة (طوابع زمنية، معرّفات، واسم حدث واضح). قرر إن كنت ستفرض المخططات من البداية أو تتطور بحذر مع الزمن.
ينجح كافكا عندما يمتلك شخص ما:
أضف المراقبة فورًا (تأخر المستهلكين، صحة الوسطاء، معدل النقل، معدلات الأخطاء). إذا لم يكن لديك فريق منصة بعد، ابدأ بعرض مُدار وحدود واضحة.
أنتج أحداثًا من نظام واحد، واستهلكها في مكان واحد، وأثبت الحلقة من البداية للنهاية. ثم وسّع لتمكين مزيد من المستهلكين، والأقسام، والتكاملات.
إذا أردت التحرك بسرعة من "فكرة" إلى خدمة مدفوعة بالأحداث تعمل، أدوات مثل Koder.ai يمكن أن تساعدك في تصميم التطبيق المحيط بسرعة (واجهة React، خادم Go، PostgreSQL) وإضافة منتجين/مستهلكين لكافكا تدريجيًا عبر سير عمل مدفوع بالدردشة. مفيدة خصوصًا لبناء لوحات داخلية وخدمات خفيفة تستهلك المواضيع، مع ميزات مثل وضع التخطيط، تصدير الشيفرة المصدرية، النشر/الاستضافة، والت.snapshots مع الرجوع.
إذا كنت تُسقط هذا ضمن نهج مدفوع بالأحداث، انظر /blog/event-driven-architecture. للتخطيط للتكاليف والبيئات، تحقق من /pricing.
كافكا منصة توزيع تدفق الأحداث تخزن الأحداث في سجلات دائمة تضاف إليها فقط.
يكتب المنتجون (producers) الأحداث إلى المواضيع، ويقرأها المستهلكون (consumers) بشكل مستقل (غالبًا في الوقت الحقيقي، وأحيانًا لاحقًا) لأن كافكا يحتفظ بالبيانات لفترة قابلة للتهيئة.
استخدم كافكا عندما تحتاج عدة أنظمة إلى نفس تدفق الأحداث، وتريد فك الترابط (loose coupling)، وقد تحتاج إلى إعادة تشغيل التاريخ (replay).
هو مفيد بشكل خاص في:
الموضوع (topic) هو فئة مسماة من الأحداث (مثل orders أو payments).
القسم (partition) هو جزء من الموضوع يتيح:
كافكا يضمن الترتيب فقط ضمن قسم واحد.
يستخدم كافكا المفتاح (key) للسجل (مثل order_id) لتوجيه الأحداث ذات الصلة دائمًا إلى نفس القسم.
قاعدة عملية: إذا احتجت ترتيبًا لكل كيان (مثل طلب/عميل)، اختر مفتاحًا يمثل هذا الكيان حتى تهبط أحداثه في قسم واحد.
مجموعة المستهلكين (consumer group) هي مجموعة من مثيلات المستهلك التي تتشارك العمل على موضوع ما.
داخل المجموعة:
إذا احتجت أن يحصل تطبيقان مختلفان على كل حدث، فكلٌ منهما يجب أن يستخدم مجموعة مستهلكين مختلفة.
يحفظ كافكا الأحداث على القرص وفق سياسات الاحتفاظ حتى يتمكن المستهلكون من اللحاق بالركب بعد تعطلهم أو إعادة معالجة التاريخ.
أنواع الاحتفاظ الشائعة:
الاحتفاظ يُضبط لكل موضوع، لذا يمكن أن تبقي الموضوعات الخاصة بالتدقيق وقتًا أطول من موضوعات القياس العالية الحجم.
الضغط اللوغاريتمي (log compaction) يحتفظ على الأقل بآخر سجل لكل مفتاح، ويزيل السجلات القديمة التي تم تجاوزها بمرور الوقت.
مناسب لتيارات "الحالة الحالية" (مثل إعدادات العميل أو ملفات التعريف) حيث تهتم بأحدث قيمة لكل مفتاح بدلاً من كل تغيير تاريخي—مع الحفاظ على مصدر موثوق لأحدث الحالة.
النمط الأكثر شيوعًا في كافكا من الطرف إلى الطرف هو على الأقل مرة واحدة (at-least-once): لن تفقد أحداثًا، لكن قد تحدث تكرارات.
للتعامل مع ذلك بأمان:
الإزاحات (offsets) هي "إشارة مرجعية" للمستهلك لكل قسم.
إذا قمت بتأكيد الإزاحة مبكرًا فقد تفقد العمل عند التعطل؛ وإذا أكدت متأخرًا فستُعاد معالجة وتُنتج تكرارات بعد الفشل.
نمط عملي شائع: تكرار محدود مع تراجع (backoff)، ثم نشر السجل الفاشل إلى موضوع رسائل ميتة (dead-letter topic) حتى لا يمنع رسالة واحدة المجموعة بأكملها.
Kafka Connect يحرّك البيانات من/إلى كافكا باستخدام موصلات (مصادر ومصارف) بدل كتابتك كود تكاملي خاص.
Kafka Streams مكتبة لمعالجة التدفقات في الزمن الحقيقي داخل التطبيقات: تصفية، إثراء، انضمام، وبناء مجموعات.
بشكل مختصر: Connect للتكامل؛ Streams للحساب والمعالجة داخل التطبيق.