كتاب "أباتشي كافكا. معالجة الدفق وتحليل البيانات "

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

لمن هذا الكتاب؟

"أباتشي كافكا. معالجة الدفق وتحليل البيانات "للمطورين الذين يستخدمون واجهة برمجة تطبيقات Kafka في عملهم ، بالإضافة إلى مهندسي العمليات (يطلق عليهم أيضًا SRE أو DevOps أو مسؤولي النظام) الذين يشاركون في تثبيت وتكوين وتكوين ومراقبة عملها أثناء التشغيل الصناعي. لم ننسى أيضًا مهندسي البيانات والمهندسين التحليليين - أولئك المسؤولون عن تصميم وإنشاء البنية التحتية الكاملة للبيانات في الشركة. بعض الفصول ، خاصة 3 و 4 و 11 ، تستهدف مطوري جافا. لفهمها ، من المهم أن يكون القارئ على دراية بأساسيات لغة برمجة Java ، بما في ذلك قضايا مثل معالجة الاستثناء والمنافسة.

الفصول الأخرى ، خاصة 2 و 8 و 9 و 10 ، تفترض أن القارئ لديه خبرة مع Linux ومألوفًا لإعداد شبكة Linux والتخزين. تتم مناقشة ما تبقى من كتاب كافكا وهندسة البرمجيات بعبارات أكثر عمومية ، لذلك لا يلزم معرفة خاصة من القراء.

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

الفصل 2. تثبيت كافكا

Apache Kafka هو تطبيق Java يمكن تشغيله على العديد من أنظمة التشغيل ، بما في ذلك Windows و MacOS و Linux وغيرها ، وسنركز في هذا الفصل على تثبيت Kafka على Linux ، حيث إنه النظام الأساسي الذي يتم تثبيته في الغالب على نظام التشغيل هذا. لينكس هو أيضًا نظام التشغيل الموصى به لنشر كافكا للأغراض العامة. للحصول على معلومات حول تثبيت Kafka على نظامي التشغيل Windows و MacOS ، راجع الملحق أ.

تثبيت جافا

قبل تثبيت ZooKeeper أو Kafka ، يجب تثبيت بيئة Java وتكوينها. من المستحسن استخدام Java 8 ، وقد يكون هذا إصدارًا ، إما مضمن في نظام التشغيل الخاص بك أو تم تنزيله مباشرة من java.com. على الرغم من أن ZooKeeper و Kafka سيعملان مع Java Runtime Edition ، إلا أنه من الملائم أكثر استخدام مجموعة تطوير Java الكاملة (JDK) عند تطوير الأدوات والتطبيقات. تفترض خطوات التثبيت هذه أن لديك JDK الإصدار 8.0.51 مثبتًا في الدليل /usr/java/jdk1.8.0_51.

قم بتثبيت ZooKeeper

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


تم اختبار Kafka بدقة مع الإصدار المستقر 3.4.6 من مستودع ZooKeeper ، والذي يمكن تنزيله من apache.org.

خادم مستقل

يوضح المثال التالي تثبيت ZooKeeper بالإعدادات الأساسية في دليل / usr / local / zookeeper وحفظ البيانات في دليل / var / lib / zookeeper:

# tar -zxf zookeeper-3.4.6.tar.gz # mv zookeeper-3.4.6 /usr/local/zookeeper # mkdir -p /var/lib/zookeeper # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF > tickTime=2000 > dataDir=/var/lib/zookeeper > clientPort=2181 > EOF # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # 

الآن يمكنك التحقق من أنه من المفترض أن يعمل ZooKeeper في وضع عدم الاتصال عن طريق الاتصال بمنفذ العميل وإرسال أمر srvr المكون من أربعة أحرف:

 # telnet localhost 2181 Trying ::1... Connected to localhost. Escape character is '^]'. srvr Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT Latency min/avg/max: 0/0/0 Received: 1 Sent: 0 Connections: 1 Outstanding: 0 Zxid: 0x0 Mode: standalone Node count: 4 Connection closed by foreign host. # 

فرقة حديقة الحيوان

تسمى مجموعة ZooKeeper مجموعة. نظرًا لطبيعة الخوارزمية نفسها ، يوصى بأن تتضمن المجموعة عددًا فرديًا من الخوادم ، على سبيل المثال ، 3 ، 5 ، وما إلى ذلك ، لأنه حتى يتمكن ZooKeeper من الاستجابة للطلبات ، يجب أن تعمل غالبية أعضاء المجموعة (النصاب القانوني). هذا يعني أن مجموعة من ثلاث عقد يمكن أن تعمل مع عقدة خاملة واحدة. إذا كانت المجموعة تحتوي على ثلاث عقد ، فقد يكون هناك عقدان.

لتكوين تشغيل خوادم ZooKeeper في المجموعة ، يجب أن يكون لديهم تكوين واحد مع قائمة بجميع الخوادم ، ويجب أن يكون لكل خادم في دليل البيانات ملف myid بمعرف هذا الخادم. إذا تمت تسمية المضيفين في المجموعة باسم zoo1.example.com و zoo2.example.com و zoo3.example.com ، فقد يبدو ملف التكوين كما يلي:

 tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=20 syncLimit=5 server.1=zoo1.example.com:2888:3888 server.2=zoo2.example.com:2888:3888 server.3=zoo3.example.com:2888:3888 

في هذا التكوين ، initLimit هو مقدار الوقت الذي يمكن للعقد التابعة فيه الاتصال بالسيد. تحدد قيمة syncLimit تأخر العقد التابعة من الرئيسية. يتم تحديد كلتا القيمتين في وحدات TickTime ، أي initLimit = 20 · 2000 ms = 40 s. يسرد التكوين أيضًا جميع خوادم المجموعات. هم في تنسيق الخادم. X = hostname: peerPort: leaderPort بالمعلمات التالية:

• X هو معرّف الخادم. يجب أن يكون عددًا صحيحًا ، ولكن قد لا يكون العدد من الصفر ولا يكون متسلسلًا ؛
• اسم المضيف - اسم المضيف أو عنوان IP للخادم ؛
• peerPort - منفذ TCP يتم من خلاله اتصال خوادم المجموعات ببعضها البعض ؛
• leaderPort - منفذ TCP يتم من خلاله تحديد المضيف.

يكفي أن يتمكن العملاء من الاتصال بالمجموعة من خلال منفذ clientPort ، ولكن يجب أن يتمكن أعضاء المجموعة من تبادل الرسائل مع بعضهم البعض على جميع المنافذ الثلاثة.

بالإضافة إلى ملف تكوين واحد ، يجب أن يكون لكل خادم في دليل dataDir ملف myid. يجب أن يحتوي على معرف الخادم المطابق للمعرف الوارد في ملف التكوين. بعد الانتهاء من هذه الخطوات ، يمكنك بدء تشغيل الخوادم وستتفاعل مع بعضها البعض في المجموعة.

تركيب كافكا بروكر

بعد الانتهاء من تكوين Java و ZooKeeper ، يمكنك متابعة تثبيت Apache Kafka. يمكن تنزيل أحدث إصدار من Apache Kafka على kafka.apache.org/downloads.html .

في المثال التالي ، قم بتثبيت منصة Kafka في دليل / usr / local / kafka ، وقم بتكوينه لاستخدام خادم ZooKeeper الذي تم تشغيله مسبقًا وحفظ مقاطع سجل الرسائل في دليل / tmp / kafka-logs:

 # tar -zxf kafka_2.11-0.9.0.1.tgz # mv kafka_2.11-0.9.0.1 /usr/local/kafka # mkdir /tmp/kafka-logs # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

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

إنشاء وفحص المواضيع:

 # /usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test Created topic "test". # /usr/local/kafka/bin/kafka-topics.sh --zookeeper localhost:2181 --describe --topic test Topic:test PartitionCount:1 ReplicationFactor:1 Configs: Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0 # 

إنشاء رسائل لموضوع الاختبار:

 # /usr/local/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test Test Message 1 Test Message 2 ^D # 

استهلاك الرسائل من موضوع الاختبار:

 # /usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning Test Message 1 Test Message 2 ^C Consumed 2 messages # 

تكوين الوسيط

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

إعدادات الوسيط الأساسية

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

broker.id

يجب أن يكون لكل وسيط Kafka معرف صحيح محدد بواسطة المعلمة broker.id. بشكل افتراضي ، هذه القيمة هي 0 ، ولكن يمكن أن تكون أي رقم. الشيء الرئيسي هو أنه لا يتكرر داخل نفس مجموعة كافكا. يمكن أن يكون اختيار الرقم تعسفيًا ، وإذا لزم الأمر ، من أجل راحة الصيانة ، يمكن نقله من وسيط إلى آخر. من المستحسن أن يكون هذا الرقم مرتبطًا بطريقة أو بأخرى بالمضيف ، ثم تكون مراسلات معرفات الوسيط للمضيفين مع التتبع أكثر شفافية. على سبيل المثال ، إذا كانت أسماء المضيفين تحتوي على أرقام فريدة (على سبيل المثال ، host1.example.com ، host2.example.com ، إلخ) ، فستكون هذه الأرقام خيارًا جيدًا لقيم broker.id.

ميناء

يبدأ ملف التكوين النموذجي Kafka مع مستمع على منفذ TCP 9092. يمكن تغيير هذا المنفذ إلى أي منفذ آخر متاح عن طريق تغيير منفذ معلمة التكوين. ضع في اعتبارك أنه عند اختيار منفذ برقم أقل من 1024 ، يجب تشغيل Kafka كجذر. لا يوصى بتشغيل كافكا كجذر.

zookeeper.connect

يتم تعيين المسار الذي يستخدمه ZooKeeper لتخزين بيانات تعريف الوسيط باستخدام معلمة التكوين zookeeper.connect. في تكوين العينة ، يعمل ZooKeeper على المنفذ 2181 على المضيف المحلي ، والذي يشار إليه على أنه localhost: 2181. تنسيق هذه المعلمة هو قائمة مفصولة بفواصل منقوطة لخطوط اسم مضيف النموذج: port / path ، بما في ذلك:

• اسم المضيف - اسم المضيف أو عنوان IP لخادم ZooKeeper ؛
• المنفذ - رقم منفذ العميل للخادم ؛
• / path - مسار ZooKeeper اختياري يُستخدم كمسار جذر جديد (chroot) من مجموعة Kafka. إذا لم يتم تحديده ، يتم استخدام مسار الجذر.

إذا كان مسار chroot المحدد غير موجود ، فسيتم إنشاؤه عندما يبدأ الوسيط.

سجلات

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

num.recovery.threads.per.data.dir

يستخدم Kafka تجمع مؤشر ترابط مخصص لمعالجة مقاطع السجل. يتم تطبيقه حاليًا:

• أثناء بدء التشغيل العادي - لفتح مقاطع السجل لكل قسم ؛
• البدء بعد الفشل - للتحقق من مقاطع السجل لكل قسم واقتطاعها ؛
• إيقاف - لإغلاق مقاطع السجل برفق.

بشكل افتراضي ، يتم استخدام مؤشر ترابط واحد فقط لكل دليل سجل. نظرًا لأن هذا يحدث فقط عند البدء والتوقف ، فمن المنطقي استخدام المزيد منها من أجل موازاة العمليات. عند التعافي من إيقاف تشغيل غير صحيح ، يمكن أن تصل فوائد استخدام هذا النهج إلى عدة ساعات إذا تم إعادة تشغيل الوسيط الذي يحتوي على عدد كبير من الأقسام! تذكر أنه يتم تحديد قيمة هذه المعلمة بناءً على دليل سجل واحد من الرقم المحدد باستخدام log.dirs. أي ، إذا كانت قيمة المعلمة num.recovery.threads.per.data.dir هي 8 ، وتم تحديد ثلاثة مسارات في log.dirs ، فإن العدد الإجمالي لمؤشرات الترابط هو 24.

auto.create.topics.enable

وفقًا للتكوين الافتراضي لـ Kafka ، يجب على الوسيط إنشاء سمة تلقائيًا عندما:

• يبدأ الصانع في الكتابة في سطر الموضوع ؛
• يبدأ المستهلك في القراءة من موضوع الرسالة ؛
• يطلب أي عميل البيانات الوصفية للموضوع.

في كثير من الحالات ، قد يكون هذا السلوك غير مرغوب فيه ، خاصة لأنه لا توجد طريقة للتحقق من وجود موضوع باستخدام بروتوكول كافكا دون التسبب في إنشائه. إذا كنت تتحكم في إنشاء ذلك بشكل صريح أو يدوي أو من خلال نظام التهيئة ، فيمكنك تعيين المعلمة auto.create.topics.enable على false.

إعدادات السمة الافتراضية

يحدد تكوين خادم Kafka الكثير من الإعدادات الافتراضية للموضوعات التي تم إنشاؤها. يمكن تعيين بعض هذه المعلمات ، بما في ذلك عدد الأقسام ومعلمات حفظ الرسائل ، لكل موضوع على حدة باستخدام أدوات الإدارة (الموضحة في الفصل 9). يجب تعيين القيم الافتراضية في تكوين الخادم مساوية للقيم المرجعية المناسبة لمعظم موضوعات المجموعة.

عدد الأقسام

تحدد المعلمة num.partitions عدد الأقسام التي يتم إنشاء موضوع جديد لها ، بشكل رئيسي عند تمكين الإنشاء التلقائي حسب السمات (وهو السلوك الافتراضي). القيمة الافتراضية لهذه المعلمة هي 1. ضع في اعتبارك أنه يمكن زيادة عدد أقسام الموضوع فقط ، ولكن لا يتم تقليله. هذا يعني أنه إذا كان يتطلب أقسامًا أقل مما هو مذكور في num.partitions ، فسيتعين عليك إنشائه بعناية يدويًا (هذا موضح في الفصل 9).

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

log.retention.ms

غالبًا ما يكون تخزين الرسائل في كافكا محدودًا في الوقت. يتم تحديد القيمة الافتراضية في ملف التكوين باستخدام المعلمة log.retention.hours وتساوي 168 ساعة أو أسبوع واحد. ومع ذلك ، يمكنك استخدام معلمتين أخريين - log.retention.minutes و log.retention.ms. تحدد هذه المعلمات الثلاث نفس الشيء - الفترة الزمنية التي يتم بعدها حذف الرسائل. ولكن يُنصح باستخدام المعلمة log.retention.ms ، لأنه إذا تم تحديد العديد من المعلمات ، فإن الأولوية تنتمي إلى أصغر وحدة قياس ، لذلك سيتم استخدام قيمة log.retention.ms دائمًا.

log.retention.bytes

هناك طريقة أخرى للحد من صلاحية الرسائل تعتمد على الحجم الإجمالي (بالبايت) للرسائل المخزنة. يتم تعيين القيمة باستخدام المعلمة log.retention.bytes ويتم تطبيقها بشكل منفصل. هذا يعني أنه في حالة وجود موضوع من ثمانية أقسام وتساوي 1 جيجا بايت من قيمة log.retention.bytes ، فإن الحد الأقصى لكمية البيانات المخزنة لهذا الموضوع سيكون 8 جيجا بايت. لاحظ أن مقدار التخزين يعتمد على الأقسام الفردية وليس على الموضوع. هذا يعني أنه إذا زاد عدد أقسام الموضوع ، فسيزداد أيضًا الحد الأقصى من البيانات المحفوظة عند استخدام log.retention.bytes.

log.segment.bytes

إعدادات التسجيل المذكورة تتعلق بمقاطع السجل ، وليس الرسائل الفردية. كما يتم إنشاء الرسائل من قبل وسيط Kafka ، تتم إضافتها إلى نهاية مقطع اليومية الحالي من القسم المقابل. عندما يصل مقطع السجل إلى الحجم المحدد بواسطة المعلمة log.segment.bytes ويساوي 1 غيغابايت بشكل افتراضي ، يتم إغلاق هذا المقطع ويفتح مقطع جديد. بعد الإغلاق ، يمكن سحب جزء اليومية. كلما صغر حجم مقاطع السجل ، كلما كان عليك إغلاق الملفات وإنشاء مقاطع جديدة ، مما يقلل من الكفاءة الإجمالية لعمليات الكتابة على القرص.

يعد تغيير حجم أجزاء السجل أمرًا مهمًا عندما تتميز الموضوعات بتكرار منخفض لتوليد الرسائل. على سبيل المثال ، إذا تلقى موضوع ما 100 ميغابايت فقط من الرسائل يوميًا ، وتم تعيين معلمة log.segment.bytes على القيمة الافتراضية ، فسيستغرق ملء مقطع واحد 10 أيام. وبما أنه لا يمكن اعتبار الرسائل غير صالحة حتى يتم إغلاق مقطع السجل ، فعندئذٍ بقيمة 604.8 مليون (أسبوع واحد) من معلمة log.retention.ms ، يمكن أن تتراكم الرسائل في 17 يومًا قبل سحب مقطع السجل المغلق من التداول. وذلك لأنه عند إغلاق شريحة تحتوي على رسائل تراكمت على مدار 10 أيام ، يتعين عليك تخزينها لمدة 7 أيام أخرى قبل أن تتمكن من سحبها وفقًا للقواعد المؤقتة المعتمدة ، حيث لا يمكن حذف الشريحة قبل انتهاء صلاحية الرسالة الأخيرة فيها .

log.segment.ms

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

message.max.bytes

يسمح وسيط Kafka باستخدام المعلمة message.max.bytes لتحديد الحد الأقصى لحجم الرسائل التي يتم إنشاؤها. القيمة الافتراضية لهذه المعلمة هي 1،000،000 (1 ميغابايت). ستتلقى الشركة المصنعة التي تحاول إرسال رسالة أكبر إشعارًا بالخطأ من الوسيط ، ولكن لن يتم قبول الرسالة. كما هو الحال في جميع الأحجام الأخرى بالبايت المحدد في إعدادات الوسيط ، نتحدث عن حجم الرسالة المضغوطة ، بحيث يمكن للشركات المصنعة إرسال الرسائل ، ويكون حجمها غير مضغوط أكبر بكثير إذا كان يمكن ضغطها إلى الحدود المحددة بواسطة message.max.bytes .

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

اختيار الأجهزة

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

تحتاج أولاً إلى تحديد أنواع الأداء الأكثر أهمية لنظامك ، وبعد ذلك يمكنك اختيار التكوين الأمثل للأجهزة الذي يناسب الميزانية.

إنتاجية القرص

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

الإجراء الواضح في حالة وجود مشاكل في النطاق الترددي للأقراص هو استخدام محركات الأقراص الصلبة ذات لوحات الدوران (HDD) أو محركات الأقراص ذات الحالة الصلبة (SSD). محركات الأقراص ذات الحالة الصلبة لها أوامر ذات حجم بحث أقل / وقت وصول وأداء أعلى. محركات الأقراص الصلبة أكثر اقتصادا ولها سعة نسبية أعلى. يمكن تحسين أداء محرك الأقراص الثابتة نظرًا لعددهم الأكبر في الوسيط ، أو باستخدام العديد من دلائل البيانات ، أو عن طريق تثبيت الأقراص في مجموعة من الأقراص المستقلة ذات التكرار (RAID). تؤثر العوامل الأخرى على الإنتاجية ، على سبيل المثال ، تقنية تصنيع القرص الصلب (على سبيل المثال ، SAS أو SATA) ، بالإضافة إلى خصائص وحدة تحكم القرص الثابت.

سعة القرص

السعة هي جانب آخر من التخزين. يتم تحديد المقدار المطلوب من مساحة القرص من خلال عدد الرسائل التي يجب تخزينها في نفس الوقت. إذا كان من المتوقع أن يتلقى الوسيط 1 تيرابايت من حركة المرور يوميًا ، فمع التخزين لمدة 7 أيام ، سيحتاج إلى التخزين المتاح لأجزاء السجل التي لا تقل عن 7 تيرابايت. يجب أن تفكر أيضًا في تجاوز بنسبة 10 ٪ على الأقل للملفات الأخرى ، دون احتساب المخزن المؤقت لتقلبات حركة المرور المحتملة أو نموها بمرور الوقت.

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

الذاكرة

في الوضع العادي للتشغيل ، يقرأ المستهلك كافكا من نهاية القسم ، والمستهلك يعوض باستمرار عن الوقت الضائع ويتخلف قليلاً عن الشركات المصنعة ، على الإطلاق. , , . , , -.

Kafka JVM . , X X , 5 . Kafka . Kafka , , , Kafka.

, Kafka, . ( ) . Kafka ( ) . 1 , , . , (. 6) ( 8). , .

وحدة المعالجة المركزية

, , . . Kafka, , . . Kafka ' . .

Kafka

Kafka , , Amazon Web Services (AWS). AWS , CPU, . Kafka. , . / SSD. (, AWS Elastic Block Store). CPU .
, AWS m4 r3. m4 , , . r3 SSD-, . i2 d2.

Kafka

Kafka , (. 2.2). — . — . Kafka . Kafka. 6.

?

Kafka . — . 10 , 2 , — . , 100 % ( ) (. 6). , .

, , — . , ( ). 80 % , , . , , . , , .

Kafka. — zookeeper.connect. ZooKeeper . — broker.id. broker.id , . , , , .

Linux , , Kafka. , , . /etc/sysctl.conf, Linux, .

Linux . , «» , Kafka.
, , , () . , , Kafka. , Kafka , , .

— . — , - . . vm.swappiness , 1. ( ) , . , .

, «» , , . Kafka /. : (, SSD), NVRAM (, RAID). «» , . vm.dirty_background_ratio , ( 10). ( ), 5. 0, .

«» , , vm.dirty_ratio , — 20 ( ). , 60 80. , / . vm.dirty_ratio Kafka, .

«» Kafka . /proc/vmstat:

 # cat /proc/vmstat | egrep "dirty|writeback" nr_dirty 3875 nr_writeback 29 nr_writeback_temp 0 # 

القيادة

, RAID- , . , EXT4 (fourth extended file system — ) XFS (Extents File System — ). EXT4 , . , (5), . EXT4 , . XFS , , EXT4. XFS Kafka , , . , /.

, , noatime. /: (ctime), (mtime) (atime). atime . . atime , , , ( realtime). Kafka atime, . noatime /, ctime mtime.

Linux — , , . Kafka , - . ( ) , . . net.core.wmem_default net.core.rmem_default , 2 097 152 (2 ). , , .

TCP net.ipv4.tcp_wmem net.ipv4.tcp_rmem. , , . — 4096 65536 2048000 — , 4 , — 64 , — 2 . , net.core.wmem_max net.core.rmem_max. Kafka .

. TCP 1 net.ipv4.tcp_window_scaling, . net.ipv4.tcp_max_syn_backlog , 1024, . net.core.netdev_max_backlog, 1000, , , , .

Kafka , .

Java , , . , Java 7 Garbage First (G1). G1 . , , .

G1 . .

• MaxGCPauseMillis. . — G1 . 200 . , G1 , , , , 200 .
• InitiatingHeapOccupancyPercent. , . 45. , G1 , 45 % , (Eden), .

Kafka , . 64 , Kafka 5 . 20 MaxGCPauseMillis. InitiatingHeapOccupancyPercent 35, , .

Kafka G1, . . :

 # export JAVA_HOME=/usr/java/jdk1.8.0_51 # export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true" # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Kafka , . - , . Kafka (. 6), . Kafka, .

Kafka , , ( , , AWS), , . . , «» (. 6).

: Kafka , , , . ( ) . , , .

ZooKeeper

Kafka ZooKeeper , . ZooKeeper Kafka. , ZooKeeper Kafka . ZooKeeper Kafka ( ZooKeeper , ).

ZooKeeper . ZooKeeper, Kafka, . ZooKeeper , ZooKeeper . — 1 , . ZooKeeper, , . ZooKeeper , . , Kafka Kafka ZooKeeper.

Kafka, , . Kafka ZooKeeper, . ZooKeeper, . , , , . , , .

الملخص

, Apache Kafka. , , . , Kafka, Kafka. Kafka ( 3), ( 4).

»يمكن العثور على مزيد من المعلومات حول الكتاب على موقع الناشر على الويب
» المحتويات
» مقتطفات

20% — Apache Kafka