نکاتی برای دسترسی‌پذیری و ماندگاری بالا

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

  • لطفا به هیچ وجه تاپیک با Replication Factor کم‌تر از ۳ ایجاد نکنید. هیچ‌گونه تضمین ماندگاری‌ای برای فضای ذخیره‌سازی هر کدام از بروکرها (broker) به تنهایی وجود ندارد و به هر دلیلی -از جمله موارد مورد نیاز برای عملیات‌های نگهداری و به‌روزرسانی- ممکن است داده‌های یک بروکر به طور کامل حذف و یا غیرقابل استفاده شود. همچنین بهتر است که از اعداد زوج به عنوان Replication Factor استفاده نکنید. در عملیات‌های نگهداری و به‌روزرسانی ممکن است حداکثر یک عدد از بروکر‌ها در دسترس نباشد یا داده‌های خود را از دست بدهد. همچنین توجه داشته باشید که به هیچ وجه مقدار Replication Factor یک تاپیک را بیش از تعداد بروکر‌های کلاستر تنظیم نکنید.
  • اگر سرویسی نمی‌تواند از دست رفتن پیام‌ها را تحمل کند، مقدار پارامتر ack را برابر با all تنظیم کنید. در غیر این صورت، تضمینی وجود ندارد که پیام‌ها از دست نروند. برای مثال، در عملیات‌هایی که نیازمند راه‌اندازی مجدد بروکر‌ها می‌باشند، می‌توان به طور قطع انتظار داشت که تعدادی از پیام‌ها از دست بروند. همچنین توجه داشته باشید که تنظیم پارامتر ack به تنهایی کافی نیست و نیاز است که مقدار پارامتر min.insync.replicas هم برای هر تاپیک برابر با [R/2]+1 باشد، که R تعداد رپلیکاهای هر تاپیک است.
  • توجه داشته باشید که اگر مقدار پارامتر ack را برابر با all تنظیم کنید، احتمال تکرار پیام‌ها وجود دارد، زیرا ممکن است شرایطی به وجود آید که تولیدکننده نتواند تشخیص دهد که پیام با موفقیت ارسال شده است و مجددا پیام را ارسال کند. بنابراین بهتر است که سرویس‌ را به نحوی طراحی کنید که بتواند پیام‌ تکراری را تحمل کند. اما اگر سرویسی نمی‌تواند تکراری بودن یا عوض شدن ترتیب پیام‌ها را تحمل کند، می‌توان از پارامتر enable.idempotence استفاده کرد.
  • برای مطالعه بیشتر در مورد تضمین‌های کافکا و حالت‌های مختلف تنظیمات کلاستر، می‌توانید اینجا و اینجا را مطالعه نمایید.
  • به دلیل پویایی ذاتی سرویس‌های ابری، کاربران باید انتظار قطعی ناگهانی ارتبا‌طات، اختلال‌های لحظه‌ای و تغییر آدرس IP سرویس‌ها را داشته باشند و سرویس‌های خود را با توجه به این شرایط طراحی کنند. این موارد به عنوان اختلال در سرویس‌دهی در نظر گرفته نخواهند شد. کلاینت‌های معتبر کافکا، مکانیزم‌های اتصال و تلاش مجدد پس از قطعی ناگهانی ارتبا‌طات، اختلال‌های لحظه‌ای و تغییر آدرس IP سرویس‌ها را پیاده‌سازی کرده‌اند اما نیاز است که تنظیمات و فعال بودن این مکانیزم‌ها توسط کاربر بررسی شود.
  • با نزدیک شدن به حداکثر ظرفیت نرخ نوشتن و خواندن پیام‌ها، تاخیر و نرخ خطایی که توسط سرویس‌ها احساس می‌شود افزایش پیدا می‌کند و دسترس‌پذیری کلاستر و ماندگاری پیام‌ها هم ممکن است تحت تاثیر قرار بگیرد. توجه داشته باشید که بهتر است هیچ‌گاه منابع مورد مصرف کلاستر بیش از ۷۵ درصد کل منابع در دسترس نشود.
  • نیاز است که تولیدکننده‌ها و مصرف‌کننده‌ها از سوی کاربر پایش شوند، زیرا متریک‌هایی که از سوی تولید‌کننده‌ها و مصرف‌کننده‌ها ارائه می‌شوند از طریق بروکرها قابل پایش نمی‌باشند.
  • بهتر است فقط از کتابخانه‌هایی که توسط کانفلوئنت پشتیبانی و توسعه داده می‌شوند برای توسعه تولیدکننده‌ها و مصرف‌کننده‌ها استفاده کنید. این کتابخانه‌ها از اینجا قابل مشاهده هستند. توجه داشته باشید که مسئولیت استفاده از سایر کتابخانه‌ها با کاربر است. همچنین استفاده از کتابخانه‌هایی که فرمت پیام‌ها در آن‌ها قدیمی‌تر یا جدیدتر از فرمت پیام‌ها در کلاستر است، باعث تحمیل بار پردازشی بیشتر به کلاستر به منظور تبدیل فرمت‌ها خواهد شد. بنابراین بهتر است که همیشه از نسخه‌ای از کتابخانه‌ها که فرمت پیام یکسانی با کلاستر دارند استفاده کنید.
  • با توجه به سربار مدیریتی هر پارتیشن، تعداد پارتیشن‌هایی که توسط بروکر و در نتیجه کلاستر قابل پشتیبانی می‌باشد محدود است. همچنین چون در کافکا تعداد پارتیشن‌های تاپیک‌ها قابل کاهش نمی‌باشد، بهتر است همواره با کم‌ترین تعداد پارتیشن‌ شروع کنید و سپس با توجه به عملکرد کلاستر، تعداد پارتیشن‌ها را افزایش دهید. همچنین نیاز است نرخ ورود داده‌ها به پارتیشن‌های تاپیک‌ها را در نظر داشته باشید و پارامترهای *.retention را به ازای هر تاپیک بررسی و تنظیم نمایید تا دچار کمبود فضای ذخیره‌سازی و در نتیجه از دسترس خارج شدن کلاستر و از دست رفتن پیام‌ها نشوید. همچنین برای توزیع یکنواخت داده‌ها بین پارتیشن‌های یک تاپیک و نیز بروکرهای کلاستر، در زمان نوشتن پیام‌ها از Random Partitioning استفاده نمایید مگر اینکه برای استفاده نکردن از آن دلیلی وجود داشته باشد. همچنین توجه کنید که لیدر پارتیشن‌ها به خوبی بین بروکرها توزیع شود. هر پارتیشن لیدر بسیار بیشتر از پارتیشن‌های دنبال کننده از منابع شبکه استفاده خواهد کرد زیرا تولید‌کننده‌ها داده‌های خود را بر روی این پارتیشن‌ می‌نویسند و مصرف‌کننده‌ها هم داده‌ها را از این پارتیشن‌ می‌خوانند. همچنین پارتیشن‌های دنبال کننده هم داده‌ها را از پارتیشن لیدر می‌خوانند. همچنین پارتیشن لیدر بیشتر از پارتیشن‌های دنبال کننده منبع ذخیره‌سازی را درگیر می‌کند زیرا پارتیشن لیدر هم داده‌ها را بر روی منبع ذخیره‌سازی می‌نویسد و هم ممکن است داده‌ها را از روی منبع ذخیره‌سازی بخواند اما پارتیشن‌های دنبال کننده فقط داده‌ها را بر روی منبع ذخیره‌سازی می‌نویسند. با تنظیمات پیش‌فرض، توزیع پارتیشن‌های لیدر به طور خودکار و دوره‌ای صورت می‌گیرد.
  • برای مطالعه بیشتر در مورد نحوه بهبود یا تغییر عملکرد کافکا و همچنین سرویس‌های خود، می‌توانید اینجا را مطالعه نمایید.
  • در نهایت و به عنوان مهم‌ترین نکته که عمدتا از همه موارد کم‌تر مورد توجه قرار می‌گیرد، نیاز است که همواره بخشی از زمان خود را صرف آموزش نحوه استفاده از کافکا به توسعه‌دهنده‌ها کنید. همچنین توجه داشته باشید که کافکا عمدتا در مسائل با تعداد زیادی پیام مورد استفاده قرار می‌گیرد و ممکن است ابزار مناسبی برای حل بسیاری از مسائل با تعداد اندکی پیام نباشد.
آیا این مقاله به شما کمک کرد؟

با نظر دادن به بهبود کیفیت مستندات کمک کنید

sotoon

کلیه حقوق مادی و معنوی محفوظ است. © ۱۴۰۳ ستون/ شرکت رایانش ابری واحد هزاردستان