خمسة أخطاء في قابلية التوسع يجب تجنُّبها عند استخدام تطبيق Kafka

يُعَد Apache Kafka منصة بث أحداث عالية الأداء وقابلة للتوسع بشكل كبير. لإطلاق العنان لإمكانات Kafka الكاملة، عليك أن تفكِّر بعناية في تصميم التطبيق الخاص بك. من السهل جدًا كتابة تطبيقات Kafka التي تعمل بشكل سيئ أو تصطدم في النهاية بحائط التوسع. منذ عام 2015، تقدِّم IBM خدمة IBM Event Streams، وهي خدمة Apache Kafka مُدارة بالكامل تعمل على IBM Cloud. منذ ذلك الحين، ساعدت الخدمة العديد من العملاء، بالإضافة إلى الفِرق داخل IBM، على حل مشكلات التوسع والأداء مع تطبيقات Kafka التي كتبوها.

تتناول هذه المقالة بعض المشكلات الشائعة في Apache Kafka وتقدِّم بعض التوصيات حول كيفية تجنُّب الوقوع في مشكلات قابلية التوسع مع تطبيقاتك.

1. تقليل الانتظار الناتج عن التبادل المتكرر للبيانات عبر الشبكة

تعتمد بعض عمليات Kafka على قيام العميل بإرسال البيانات إلى الوسيط وانتظار الرد. قد تستغرق الرحلة الشبكية كاملة 10 ميلي ثانية، وهذا يبدو سريعًا، إلا إنه يقتصر على ما لا يزيد عن 100 عملية في الثانية. لهذا السبب، يُنصَح بمحاولة تجنُّب هذا النوع من العمليات كلما أمكن. لحسن الحظ، يوفر لك عملاء Kafka طرقًا لتجنُّب الانتظار في هذه الأوقات التي تستغرقها هذه الرحلات ذهابًا وإيابًا. ما عليك سوى التأكد من أنك تستفيد منها.

نصائح لتحقيق أقصى قدر من الإنتاجية:

1. لا تتحقق من نجاح كل رسالة يتم إرسالها. تُتيح لك واجهة برمجة التطبيقات الخاصة بنظام Kafka فصل إرسال رسالة عن التحقق من استلام الوسيط للرسالة بنجاح. الانتظار لتأكيد استلام الرسالة قد يضيف زمن انتقال بسبب الرحلات الشبكية في تطبيقك، لذلك حاول تقليل ذلك قدر الإمكان. قد يعني هذا إرسال أكبر عدد ممكن من الرسائل قبل التحقق من استلامها جميعًا. أو قد يعني تفويض التحقق من نجاح تسليم الرسائل إلى سلسلة تنفيذ أخرى داخل تطبيقك بحيث تعمل بالتوازي مع عملية إرسال المزيد من الرسائل.
2. لا تتَّبع معالجة كل رسالة بإجراء التزام للإزاحة. تنفيذ الالتزام بعمليات الإزاحة (بشكل متزامن) يتم على شكل رحلة شبكة مع الخادم. يمكنك الالتزام بعمليات الإزاحة بشكل أقل تواترًا، أو استخدام وظيفة الالتزام غير المتزامن لتجنُّب دفع تكلفة هذه الرحلة الشبكية مع كل رسالة تتم معالجتها. ضع في اعتبارك أن الالتزام بعمليات الإزاحة بشكل أقل تواترًا قد يعني الحاجة إلى إعادة معالجة كمية أكبر من البيانات إذا تعطَّل التطبيق.

إذا قرأت ما سبق وفكرت، "ألن يجعل ذلك تطبيقي أكثر تعقيدًا؟"، فالجواب نعم، من المحتمل أن يحدث ذلك. هناك مقايضة بين الإنتاجية وتعقيد التطبيق. ما يجعل زمن الرحلة الشبكية ذهابًا وإيابًا عقبة خطيرة هو أنه بمجرد الوصول إلى هذا الحد، قد يتطلب تحقيق تحسينات إضافية في الإنتاجية تغييرات واسعة في التطبيق.

2. لا تدع زيادة أوقات المعالجة تُفهم على أنها فشل في المستهلك

إحدى الميزات المفيدة في Kafka هي أنه يراقب "حالة النشاط" للتطبيقات المستهلكة ويفصل أي تطبيق يمكن أن يكون قد تعطَّل. يتم ذلك من خلال متابعة الوسيط لآخر مرة قام فيها كل عميل مستهلك باستدعاء وظيفة "poll" (المصطلح المستخدم في Kafka لطلب المزيد من الرسائل). في حال لم يطلب العميل الرسائل بشكل متكرر بما فيه الكفاية، يعتبره الوسيط معطلًا ويقوم بفصله. تم تصميم هذا لتمكين العملاء الذين لا يواجهون مشكلات من التدخل واستلام المهام من العميل الذي تعطَّل.

للأسف، مع هذه الطريقة لا يستطيع وسيط Kafka التمييز بين العميل الذي يستغرق وقتًا طويلًا لمعالجة الرسائل التي استلمها والعميل الذي فشل فعليًا. ضَع في اعتبارك تطبيقًا مستهلكًا يعمل على حلقة: 1) يستدعي poll ويحصل على دفعة من الرسائل؛ أو 2) يعالج كل رسالة في الدفعة، مع استغراق ثانية واحدة لمعالجة كل رسالة.

إذا كان هذا المستهلك يستقبل دفعات من 10 رسائل، فسيكون الفاصل الزمني بين كل استدعاء لـ poll حوالي 10 ثوانٍ. بشكل افتراضي، يسمح Kafka بفاصل يصل إلى 300 ثانية (5 دقائق) بين الاستدعاءات لـ poll قبل فصل العميل، لذا كل شيء سيعمل بشكل طبيعي في هذا السيناريو. لكن ماذا يحدث في يوم مزدحم جدًا عندما يبدأ تراكم الرسائل على الموضوع الذي يستهلك منه التطبيق؟ بدلًا من استرجاع 10 رسائل فقط من كل استدعاء لـ poll، يحصل تطبيقك على 500 رسالة (وهو العدد الأقصى للرسائل التي يمكن إرجاعها بشكل افتراضي لكل استدعاء poll). وهذا سيؤدي إلى استغراق وقت معالجة كافٍ بحيث يقرر Kafka أن مثيل التطبيق قد فشل ويفصله. وهذه أخبار سيئة.

ستسعد عندما تعلم أن الأمر يمكن أن يزداد سوءًا. من الممكن أن يحدث نوع من حلقة تفاعلية. مع بدء Kafka بفصل العملاء لأنهم لا يستدعون poll بشكل متكرر بما يكفي، يقل عدد مثيلات التطبيق المتاحة لمعالجة الرسائل. تزداد احتمالية وجود تراكم كبير من الرسائل على الموضوع، ما يؤدي إلى زيادة احتمال حصول المزيد من العملاء على دفعات كبيرة من الرسائل واستغراقهم وقتًا طويلًا لمعالجتها. في نهاية المطاف، تدخل جميع مثيلات التطبيق المستهلك في حلقة إعادة تشغيل، ولا يتم إنجاز أي عمل مفيد.

ما الخطوات التي يمكن اتخاذها لتجنُّب حدوث ذلك؟

1. يمكن تكوين الحد الأقصى للوقت بين استدعاءات poll باستخدام تكوين Kafka للمستهلك "max.poll.interval.ms" . يمكن أيضًا تكوين الحد الأقصى لعدد الرسائل التي يمكن إرجاعها من أي استدعاء poll واحد باستخدام التكوين "max.poll.records" . كقاعدة عامة، حاول تقليل قيمة "max.poll.records" بدلًا من زيادة "max.poll.interval.ms"، لأن تعيين فترة استدعاء poll طويلة جدًا سيجعل Kafka يستغرق وقتًا أطول لتحديد العملاء الذين فشلوا فعليًا.
2. يمكن أيضًا توجيه مستهلكي Kafka لإيقاف تدفق الرسائل مؤقتًا ثم استئنافه. إيقاف الاستهلاك يمنع طريقة poll من إعادة أي رسائل، لكنه لا يزال يُعيد ضبط المؤقت المستخدم لتحديد إذا ما كان العميل قد فشل. يُعَد إيقاف الاستهلاك واستئنافه استراتيجية مفيدة إذا كنت: أ) تتوقع أن معالجة كل رسالة قد تستغرق وقتًا طويلًا؛ و ب) تريد أن يتمكن Kafka من اكتشاف فشل العميل أثناء معالجة رسالة فردية.
3. لا تتجاهل فائدة مقاييس أداء عميل Kafka. موضوع المقاييس قد يستحق مقالًا كاملًا بمفرده، لكن في هذا السياق يوفر المستهلك مقاييس لكلٍّ من متوسط وأقصى مدة بين استدعاءات poll. مراقبة هذه المقاييس يمكن أن تساعد على تحديد الحالات التي يكون فيها النظام التابع هو السبب في استغراق كل رسالة مستلمة من Kafka وقتًا أطول من المتوقع للمعالجة.

سنعود لموضوع فشل المستهلكين لاحقًا في هذا المقال، عندما نناقش كيف يمكن أن يؤدي ذلك إلى إعادة توازن مجموعة المستهلكين والتأثير المُربك الذي قد يحدث.

3. تقليل تكلفة المستهلكين الخاملين

في الخلفية، يعمل البروتوكول الذي يستخدمه مستهلك Kafka لاستلام الرسائل عن طريق إرسال طلب "إحضار" إلى وسيط Kafka. كجزء من هذا الطلب، يوضِّح العميل ما يجب على الوسيط فعله إذا لم تتوفر رسائل، بما في ذلك المدة التي يجب أن ينتظرها الوسيط قبل إرسال استجابة فارغة. بشكل افتراضي، يوجِّه مستهلكو Kafka الوسطاء للانتظار حتى 500 ميلي ثانية (يتم التحكم بهذا عبر تكوين المستهلك "fetch.max.wait.ms") حتى يتوفر على الأقل بايت واحد من البيانات (يتم التحكم بذلك باستخدام "fetch.min.bytes") .

الانتظار لمدة 500 ميلي ثانية قد يبدو منطقيًا، لكن إذا كان لدى تطبيقك مستهلكون معظم الوقت في حالة خمول، وتمت توسعته ليصل إلى 5,000 مثيل، فهذا يعني احتمال وجود 2,500 طلب في الثانية لا تفعل أي شيء على الإطلاق. كل واحد من هذه الطلبات يستهلك وقت المعالج (CPU) في الوسيط لمعالجته، وفي أقصى الحالات قد يؤثِّر ذلك في أداء واستقرار عملاء Kafka الذين يريدون القيام بمهام فعلية.

عادةً، يتمثل نهج Kafka في التوسع بإضافة المزيد من الوسطاء، ثم إعادة توزيع أقسام الموضوع (partitions) بالتساوي عبر جميع الوسطاء، القدامى والجُدُد. للأسف، قد لا يساعد هذا النهج إذا كان عملاؤك يرسلون إلى Kafka طلبات "إحضار" غير ضرورية بكثرة. سيرسل كل عميل طلبات الإحضار إلى كل وسيط يقود قسم الموضوع (partition) الذي يستهلك منه الرسائل. لذلك، من الممكن أنه حتى بعد توسيع مجموعة Kafka وإعادة توزيع الأقسام، سيظل معظم العملاء يرسلون طلبات إحضار إلى معظم الوسطاء.

فما الذي يمكنك فعله إذن؟

1. قد يساعد تغيير تكوين مستهلك Kafka على تقليل هذا التأثير. إذا كنت تريد تلقي الرسائل فور وصولها، يجب أن تبقى قيمة "fetch.min.bytes" على الحالة الافتراضية 1؛ أما إعداد "fetch.max.wait.ms" فيمكن رفعه إلى قيمة أكبر، ما يقلل عدد الطلبات المرسلة من المستهلكين الخاملين.
2. على نطاق أوسع، هل يحتاج تطبيقك إلى وجود آلاف النسخ المحتملة، حيث يستهلك كل منها من Kafka بشكل نادر؟ قد تكون هناك أسباب وجيهة لذلك، ولكن ربما توجد طرق يمكن من خلالها تصميم التطبيق لاستخدام Kafka على نحو أكثر كفاءة. وسنتناول بعض هذه الاعتبارات في القسم التالي.

4. اختيار الأعداد المناسبة من الموضوعات والأقسام

إذا كنت معتادًا على أنظمة النشر والاشتراك الأخرى (مثل بروتوكول Message Queuing Telemetry Transport المعروف بالاختصار MQTT)، فقد تتوقع أن تكون موضوعات Kafka خفيفة جدًا، وشبه مؤقتة. إنها ليست كذلك. يتعامل Kafka يتعامل بشكل أفضل مع عدد من الموضوعات يُقاس بالآلاف. ومن المتوقع أيضًا أن تكون موضوعات Kafka طويلة العمر نسبيًا. الممارسات مثل إنشاء موضوع لتلقي رسالة واحدة فقط ثم حذف الموضوع نادرًا ما يتم استخدامها مع Kafka ولا تستفيد من نقاط القوة فيه.

بدلًا من ذلك، من الأفضل التخطيط لموضوعات ذات عمر طويل. ربما تشترك في مدة حياة التطبيق أو النشاط نفسه. كما يُنصَح بالحد من عدد الموضوعات ليصل إلى مئات أو ربما آلاف قليلة. وقد يتطلب هذا تبنّي منظور مختلف حول الرسائل المتداخلة في موضوع معين.

سؤال مرتبط يتكرر كثيرًا هو: كم عدد الأقسام التي يجب أن يحتويها موضوعي؟ تقليديًا، يُنصَح بالمبالغة في تقدير عدد الأقسام، لأن إضافة أقسام بعد إنشاء الموضوع لا تغيِّر تقسيم البيانات الموجودة بالفعل على الموضوع، وبالتالي قد يؤثِّر ذلك في المستهلكين الذين يعتمدون على التقسيم لضمان ترتيب الرسائل داخل القسم. هذه نصيحة جيدة؛ ومع ذلك، نود اقتراح بعض الاعتبارات الإضافية:

1. بالنسبة إلى الموضوعات التي يُتوقع أن يكون معدل نقل البيانات فيها مقاسًا بالميجابايت في الثانية، أو حيث يمكن أن يزداد معدل النقل مع توسُّع التطبيق، نوصي بشدة بأن تحتوي على أكثر من قسم واحد، حتى يمكن توزيع الحمل على عدة وسطاء. خدمة Event Streams تشغِّل دائمًا Kafka باستخدام عدد من الوسطاء يكون من مضاعفات 3. في وقت كتابة هذا النص، يصل الحد الأقصى إلى 9 وسطاء، ولكن ربما تتم زيادتهم في المستقبل. إذا اخترت عدد أقسام في موضوعك يكون من مضاعفات 3، فسيكون بالإمكان توزيعها بشكل متساوٍ على جميع الوسطاء.
2. عدد الأقسام في الموضوع يحدِّد الحد الأقصى لعدد مستهلكي Kafka الذين يمكنهم مشاركة استهلاك الرسائل من الموضوع بشكل فعَّال ضمن مجموعات المستهلكين (سيتم التوسع في هذا لاحقًا). إذا أضفت عددًا من المستهلكين إلى مجموعة مستهلكين أكثر من عدد الأقسام في الموضوع، فسيبقى بعض المستهلكين خامدين دون استهلاك بيانات الرسائل.
3. ليس هناك ما يمنع وجود موضوعات ذات قسم واحد طالما كنت متأكدًا تمامًا أنها لن تستقبل حجمًا كبيرًا من الرسائل، أو أنك لن تعتمد على ترتيب الرسائل داخل الموضوع، ويمكنك إضافة المزيد من الأقسام لاحقًا إذا أردت.

5. إعادة توازن مجموعة المستهلكين قد تكون أكثر إزعاجًا مما هو متوقع

تستفيد معظم تطبيقات Kafka التي تستهلك الرسائل من قدرات مجموعات المستهلكين في Kafka لتنسيق استهلاك العملاء من أقسام الموضوع المختلفة. إذا كان لديك بعض الغموض حول مجموعات المستهلكين، فإليك تذكيرًا سريعًا بالنقاط الرئيسية:

• تنسِّق مجموعات المستهلكين مجموعة من عملاء Kafka بحيث يستقبل عميل واحد فقط الرسائل من قسم محدد من الموضوع في أي وقت. هذا مفيد إذا كنت بحاجة إلى توزيع الرسائل في موضوع ما بين عدة نسخ من التطبيق.
• عند انضمام عميل Kafka إلى مجموعة مستهلكين أو مغادرته لمجموعة سبق له الانضمام إليها، تتم إعادة توازن مجموعة المستهلكين. عادةً، ينضم العملاء إلى مجموعة المستهلكين عند تشغيل التطبيق الذي ينتمون إليه، ويغادرون عند إيقاف التطبيق أو إعادة تشغيله أو حدوث أعطال فيه.
• عند إعادة توازن المجموعة، تتم إعادة توزيع أقسام الموضوع بين أعضاء المجموعة. على سبيل المثال، إذا انضم عميل إلى مجموعة، قد يتم سحب بعض أقسام الموضوع من العملاء الموجودين بالفعل في المجموعة (أو ما يُسمى باسم "revoked" في مصطلحات Kafka) ليتم منحها للعميل الجديد. والعكس صحيح أيضًا: عند مغادرة عميل لمجموعة، تتم إعادة توزيع أقسام الموضوع المخصصة له بين الأعضاء المتبقين.

مع نضوج كافكا، تم ابتكار خوارزميات إعادة التوازن المتطورة بشكل متزايد (ولا يزال). في الإصدارات المبكرة من Kafka، عندما تعيد مجموعة المستهلكين توازنها، كان على جميع العملاء في المجموعة التوقف عن الاستهلاك، وكانت تقسيمات المواضيع تعاد توزيعها بين الأعضاء الجدد في المجموعة ويبدأ جميع العملاء في الاستهلاك مرة أخرى. وهذا النهج له عيبان (لا تقلق، فقد تم تحسينهما منذ ذلك الحين):

1. يتوقف جميع العملاء في المجموعة عن استهلاك الرسائل أثناء حدوث إعادة التوازن. ولهذا الأمر تداعيات واضحة على الإنتاجية.
2. عادةً، يحاول عملاء Kafka الاحتفاظ بمخزن مؤقت من الرسائل التي لم يتم تسليمها بعد للتطبيق، ويُحضرون المزيد من الرسائل من الوسيط قبل أن ينفد المخزن. الهدف هو منع توقف تسليم الرسائل للتطبيق أثناء حضار المزيد من الرسائل من وسيط Kafka (نعم، كما ذُكر سابقًا في هذا المقال، يحاول عميل Kafka أيضًا تجنُّب الانتظار بسبب جولات الشبكة). للأسف، عندما تؤدي إعادة التوازن إلى سحب الأقسام من عميل ما، يجب التخلص من أي بيانات مخزَّنة مؤقتًا لتلك الأقسام. وبالمثل، عندما تؤدي إعادة التوازن إلى تخصيص قسم جديد لعميل، يبدأ العميل بتخزين البيانات مؤقتًا ابتداءً من آخر إزاحة مؤكَّدة للقسم، ما قد يسبِّب زيادة مفاجئة في معدل نقل البيانات من الوسيط إلى العميل. يحدث هذا بسبب قيام العميل الذي تم تخصيص القسم له حديثًا بإعادة قراءة بيانات الرسائل التي كانت مخزّنة مؤقتًا مسبقًا من قِبل العميل الذي تم سحب القسم منه.

حققت خوارزميات إعادة التوازن الحديثة تحسينات كبيرة من خلال إضافة ما يُعرَف في مصطلحات Kafka بـ "الالتصاق" (stickiness) و"التعاون" (cooperation).

• تحاول خوارزميات "الالتصاق" التأكد من أن أكبر عدد ممكن من أعضاء المجموعة يحتفظ بنفس الأقسام التي كان يمتلكها قبل إعادة التوازن. يقلل هذا من كمية بيانات الرسائل المخزّنة مؤقتًا التي يتم تجاهلها أو إعادة قراءتها من Kafka عند حدوث إعادة التوازن.
• تسمح خوارزميات "التعاون" للعملاء بالاستمرار في استهلاك الرسائل أثناء حدوث إعادة التوازن. عندما يكون لدى العميل قسم مخصص له قبل إعادة التوازن ويحتفظ بالقسم بعد حدوث إعادة التوازن، يمكنه الاستمرار في الاستهلاك من الأقسام المستمرة من خلال إعادة التوازن. ويتوافق هذا مع "الالتصاق"، والذي يعمل على إبقاء الأقسام المخصصة لنفس العميل.

على الرغم من هذه التحسينات التي تم إدخالها على خوارزميات إعادة التوازن الأحدث، فإذا كانت تطبيقاتك تخضع بشكل متكرر لإعادة التوازن بين مجموعات المستهلكين، فستظل ترى تأثيرًا في إجمالي معدل نقل الرسائل وإهدار عرض النطاق الترددي للشبكة حيث يتجاهل العملاء بيانات الرسائل المخزّنة مؤقتًا ثم يعيدون إحضارها. وفيما يلي بعض الاقتراحات بشأن ما يمكنك فعله:

1. تأكد من إمكانية تحديد وقت حدوث إعادة التوازن. على نطاق واسع، يُعَد جمع المقاييس وتصورها هو خيارك الأفضل. هذه هي الحالة التي تساعد فيها مجموعة واسعة من مصادر المقاييس على بناء الصورة الكاملة. يحتوي وسيط Kafka على مقاييس لكلٍّ من كمية بايتات البيانات المرسلة إلى العملاء، وكذلك عدد مجموعات المستهلكين التي تُعيد التوازن. إذا كنت تعمل على تجميع المقاييس من تطبيقك أو وقت تشغيله، والتي تُظهر متى تحدث عمليات إعادة التشغيل، فإن ربط ذلك بمقاييس الوسيط يمكن أن يوفر مزيدًا من التأكيد على أن إعادة التوازن تمثِّل مشكلة بالنسبة لك.
2. تجنَّب إعادة تشغيل التطبيقات بشكل غير ضروري عندما يتعطل التطبيق على سبيل المثال. إذا كنت تواجه مشكلات تتعلق بالاستقرار مع تطبيقك، فقد يؤدي هذا إلى إعادة التوازن بشكل متكرر أكثر مما هو متوقع. إن البحث في سجلات التطبيق عن رسائل الخطأ الشائعة الصادرة عن تعطُّل التطبيق، على سبيل المثال تتبُّعات المجموعة، يمكن أن يساعد على تحديد مدى تكرار حدوث المشكلات وتوفير معلومات مفيدة لاستكشاف المشكلة الأساسية وإصلاحها.
3. هل تستخدم أفضل خوارزمية لإعادة التوازن لتطبيقك؟ في وقت كتابة هذا المقال، كان المعيار الذهبي هو "CooperativeStickyAssignor"؛ ومع ذلك، فإن الوضع الافتراضي (اعتبارًا من Kafka 3.0) هو استخدام "RangeAssignor" (وخوارزمية التعيين السابقة) وتفضيلها على خوارزمية التعيين التعاونية. تَصِف وثائق Kafka خطوات الترحيل المطلوبة لعملائك لالتقاط خوارزمية التعيين التعاونية. تجدر الإشارة أيضًا إلى أنه على الرغم من كون "CooperativeStickyAssignor" خيارًا جيدًا وشاملًا، فإن هناك أدوات تعيين أخرى مخصصة لحالات استخدام معينة.
4. هل تم تحديد أعضاء مجموعة المستهلكين؟ على سبيل المثال، ربما تشغِّل دائمًا 4 نسخ مختلفة ومتاحة بدرجة عالية من التطبيق. قد تتمكن من الاستفادة من ميزة عضوية المجموعة الثابتة في Kafka. من خلال تعيين معرِّفات فريدة لكل مثيل لتطبيقك، تُتيح لك عضوية المجموعة الثابتة تجنُّب إعادة التوازن تمامًا.
5. قم بإجراء الإزاحة الحالية عندما يتم إبطال قسم من مثيل التطبيق الخاص بك. يوفر العميل الاستهلاكي لكافكا مستمعا لإعادة توازن الأحداث. إذا كان أحد نسخ تطبيقك على وشك إلغاء قسم منه، يوفر المستمع فرصة لالتزام إزاحة للقسم الذي على وشك أن يسحب منه. تتمثل ميزة الالتزام بتعويض عند النقطة التي يتم فيها إبطال القسم في أنه يضمن أن يلتقط القسم أيًا من أعضاء المجموعة المعين من هذه النقطة، بدلاً من احتمال إعادة معالجة بعض الرسائل من القسم.

أنت الآن خبير في توسيع نطاق تطبيقات Kafka. أنت مدعو لتطبيق هذه النقاط وتجربة العرض المُدار بالكامل لنظام Kafka على IBM Cloud. إذا واجهتك أي صعوبات في الإعداد، فيُرجى الرجوع إلى دليل بدء التشغيل والأسئلة الشائعة.