ترتیب در چه محدوده‌ای برقرار است؟
در Kafka، یک topic می‌تواند چند partition داشته باشد. هر partition ترتیب خود را دارد؛ وجود topic مشترک به معنی ترتیب سراسری همه پیام‌های همه partitionها نیست. انتخاب کلید پیام و شیوه توزیع آن، بخشی از طراحی قرارداد مصرف‌کننده است.
تکثیر داده برای دسترس‌پذیری و تحمل خرابی اهمیت دارد. بااین‌حال تنظیم تأیید نوشتن و تعداد replicaهای همگام باید کنار هم بررسی شوند. صرف نوشتن acks=all در یک برنامه، بدون فهم وضعیت replicaها و حداقل اعضای همگام، توضیح کاملی از دوام داده نمی‌دهد.
Compaction با حذف فوری فرق دارد
نمودار رسمی این صفحه نشان می‌دهد که log compaction چگونه نسخه‌های قدیمی‌تر یک کلید را کنار می‌گذارد تا وضعیت آخر آن قابل بازیابی بماند. این فرایند آنی نیست و نباید فرض کرد در هر لحظه فقط یک پیام برای هر کلید روی دیسک وجود دارد. پیام‌های حذف و سیاست‌های زمانی نگهداری نیز باید در طراحی لحاظ شوند.
یک مثال آموزشی مستقل
برای یک سامانه فرضی موجودی کالا، کلید را شناسه کالا در نظر بگیرید. اگر هدف بازسازی «آخرین وضعیت» باشد، topic فشرده‌شونده می‌تواند مناسب باشد؛ اما برای حسابرسی تمام تغییرهای موجودی، نگهداری تاریخچه کامل نیاز جداگانه‌ای است. قرار دادن این دو نیاز در یک قرارداد مبهم، بعداً بازیابی را دشوار می‌کند.
در محیط آزمایشی، قطع یک broker، عقب‌افتادن مصرف‌کننده و تکرار ارسال ناشر را جدا آزمایش کنید. نتیجه را با شناسه پیام و شمارش عملیات ثبت کنید. معیار موفقیت صرفاً سبزبودن داشبورد خوشه نیست؛ باید بدانید کدام پیام پذیرفته شده و کدام اثر تجاری واقعاً ثبت شده است.
مرز مهم
Replication نسخه پشتیبان مستقل نیست: حذف اشتباه یا تغییر نادرست سیاست می‌تواند بین replicaها بازتاب پیدا کند. راهبرد آرشیو، بازیابی و مدت نگهداری را جدا بنویسید. مبنای این مرور، مستند طراحی شاخه 4.1 است؛ تنظیمات اجرایی باید با نسخه نصب‌شده تطبیق داده شوند.
کلید پیام، قرارداد دامنه و ترتیب کاربردی
برای طراحی کلید پیام ابتدا بپرسید کدام تغییرها باید نسبت به هم مرتب بمانند. در سامانه سفارش، رویدادهای مربوط به یک سفارش معمولاً به ترتیب نیاز دارند، ولی الزاماً ترتیب میان دو سفارش مستقل مهم نیست. انتخاب شناسه سفارش به عنوان کلید، این نیاز را بهتر از توزیع تصادفی بیان می‌کند. با این حال، اگر یک کلید بسیار پرترافیک باشد، بخشی از بار روی یک پارتیشن متمرکز می‌شود. افزایش تعداد پارتیشن‌ها بدون بررسی توزیع کلیدها لزوماً این نقطه داغ را برطرف نمی‌کند.
تغییر تعداد پارتیشن‌ها را تغییر صرفاً زیرساختی فرض نکنید. در روش‌های متداول تقسیم بر اساس کلید، تغییر تعداد می‌تواند مقصد پیام‌های جدید یک کلید را عوض کند. پیام‌های قدیمی همچنان در محل قبلی هستند و مصرف هم‌زمان آنها ممکن است با انتظار ترتیب کاربردی شما سازگار نباشد. برای سامانه حساس، مهاجرت به قرارداد جدید را با تولیدکننده و مصرف‌کننده هماهنگ کنید و سناریوی عبور از مرز تغییر را در آزمایشگاه بررسی کنید.
ترتیب ورود به یک پارتیشن هم با ترتیب زمانی جهان واقعی یکسان نیست. دو تولیدکننده ممکن است ساعت‌های متفاوت یا تأخیر شبکه متفاوت داشته باشند. اگر کاربرد به زمان وقوع رویداد نیاز دارد، آن زمان را به صورت فیلد مستقل نگه دارید و سیاست داده دیررس را تعریف کنید. شماره موقعیت پیام، زمان رویداد و شناسه تجاری هر کدام مسئله متفاوتی را حل می‌کنند و نباید به جای یکدیگر استفاده شوند.
گروه مصرف‌کننده و مرز پردازش
گروه مصرف‌کننده برای تقسیم کار میان اعضا مفید است. در الگوی معمول، یک پارتیشن در یک گروه در هر لحظه به یک مصرف‌کننده اختصاص دارد. بنابراین افزودن مصرف‌کننده بیشتر از تعداد پارتیشن‌های قابل واگذاری الزاماً پردازش موازی بیشتری ایجاد نمی‌کند. گروه‌های جدا می‌توانند همان داده را برای هدف‌های متفاوت بخوانند؛ مثلاً یک گروه برای ساخت گزارش و گروه دیگر برای به‌روزرسانی جست‌وجو. هر گروه موقعیت خواندن خودش را دارد و عقب‌ماندگی یکی لزوماً به معنای عقب‌ماندگی دیگری نیست.
ثبت موقعیت مصرف باید با نقطه پایان کار هماهنگ شود. اگر موقعیت پیش از ثبت نتیجه تجاری جلو برود و برنامه متوقف شود، پیام ممکن است از دید آن گروه مصرف‌شده باشد در حالی که اثر لازم ساخته نشده است. اگر ابتدا نتیجه ثبت و سپس موقعیت ثبت شود، توقف میان این دو مرحله می‌تواند پردازش دوباره بسازد. راهکار مناسب به قرارداد برنامه بستگی دارد و معمولاً به شناسه عملیات، ثبت تکرارها و مرز تراکنش روشن نیاز دارد.
قابلیت‌های تراکنشی Kafka در محدوده مشخص خود مفیدند، ولی نباید از آنها نتیجه گرفت که هر نوشتن در یک پایگاه داده بیرونی خودبه‌خود دقیقاً یک بار انجام می‌شود. وقتی اثر نهایی خارج از سامانه پیام است، باید هماهنگی یا منطق تحمل تکرار آن اثر را جدا طراحی کرد. در گزارش معماری دقیقاً بنویسید تضمین مورد نظر از کدام ورودی تا کدام خروجی برقرار است. عبارت مبهم «پردازش دقیقاً یک بار» بدون این مرز، منشأ سوءتفاهم عملیاتی می‌شود.
تکثیر، حداقل اعضای همگام و توقف قابل انتظار
تعداد نسخه‌ها بیان می‌کند داده روی چند عضو نگهداری می‌شود، اما تصمیم پذیرش نوشتن به تنظیم تأیید و وضعیت اعضای همگام نیز وابسته است. اگر اعضای کافی برای سیاست دوام در دسترس نباشند، رد شدن نوشتن می‌تواند رفتار حفاظتی مورد انتظار باشد. خاموش کردن این محدودیت برای سبز شدن داشبورد ممکن است تعهد دوام را تغییر دهد. مالک سرویس باید بداند در چنین شرایطی برنامه پیام را کجا نگه می‌دارد، تا چه زمانی تلاش می‌کند و چگونه به کاربر پاسخ می‌دهد.
برای آزمایش، نرخ تولید کنترل‌شده و شناسه یکتای پیام داشته باشید. ابتدا یک عضو را از دسترس خارج کنید و نتیجه تأییدها را ثبت کنید. سپس وضعیت را بازگردانید و مجموعه پیام‌های پذیرفته‌شده را با پیام‌های قابل خواندن مقایسه کنید. پیام نامطمئن را از پیام قطعاً ردشده جدا کنید؛ قطع اتصال هنگام انتظار پاسخ می‌تواند نتیجه ارسال را برای تولیدکننده مبهم کند. تلاش مجدد باید با این ابهام سازگار باشد و اثر تکراری را مدیریت کند.
فشرده‌سازی برای وضعیت، آرشیو برای تاریخچه
در موضوعی که آخرین مقدار هر کلید را نگه می‌دارد، مصرف‌کننده تازه می‌تواند با خواندن داده موجود وضعیت خود را بازسازی کند. با این حال، فشرده‌سازی یک عملیات فوری حذف نیست و مصرف‌کننده باید توان پردازش چند مقدار برای یک کلید را داشته باشد. آخرین مقدار معتبر باید جایگزین مقدار قبلی شود. طراحی که فرض کند از هر کلید فقط یک رکورد در جریان دیده می‌شود، با رفتار واقعی نگهداری سازگار نیست.
حذف منطقی با رکورد ویژه حذف نیز به زمان و سیاست نگهداری وابسته است. مصرف‌کننده‌ای که برای مدت بسیار طولانی غایب بوده ممکن است نیازمند بازسازی کامل وضعیت محلی باشد. برای همین مدت مجاز آفلاین بودن مصرف‌کننده را در قرارداد بنویسید. اگر گزارش حسابرسی به همه انتقال‌های مالی نیاز دارد، موضوع فشرده‌شونده را تنها مرجع آن قرار ندهید. وضعیت آخر حساب و تاریخچه تغییر حساب دو محصول داده متفاوت‌اند و سیاست نگهداری متفاوت می‌خواهند.
تغییر ساختار پیام و سازگاری خواننده
کلید مناسب به تنهایی قرارداد داده را کامل نمی‌کند. نام فیلدها، نوع مقدار، معنای مقدار خالی و واحد اندازه‌گیری باید روشن باشند. اگر مبلغ از واحدی به واحد دیگر تغییر کند ولی نام فیلد ثابت بماند، مصرف‌کننده ممکن است بدون خطای فنی نتیجه غلط تولید کند. تغییر سازگار را با نمونه پیام قدیمی و جدید آزمایش کنید و نشان دهید نسخه‌های هم‌زمان مصرف‌کننده چه رفتاری دارند. وجود ساختار معتبر به معنای معنای تجاری درست نیست.
پیام ناسازگار نباید همیشه کل پارتیشن را بی‌اطلاع متوقف کند. سیاست برخورد می‌تواند توقف کنترل‌شده برای جلوگیری از فساد داده یا کنارگذاری ثبت‌شده در مسیر جدا باشد؛ انتخاب به اهمیت داده بستگی دارد. در هر حالت، دلیل شکست، موقعیت پیام و شناسه تجاری را نگه دارید تا اصلاح قابل تکرار باشد. ارسال محتوا به مسیر خطا نیز باید محدودیت دسترسی و نگهداری داشته باشد، زیرا داده نامعتبر ممکن است همچنان اطلاعات حساس واقعی در خود داشته باشد.
پایش عقب‌ماندگی با زمینه درست
عقب‌ماندگی را همراه با نرخ تولید و سرعت مصرف تفسیر کنید. مقدار ثابت کوچک ممکن است طبیعی باشد، اما مقدار رو به رشد نشان می‌دهد مصرف‌کننده از جریان عقب می‌افتد. زمان تقریبی رسیدن به وضعیت جاری نیز برای مالک کسب‌وکار از یک عدد خام موقعیت مفیدتر است. اگر تولید متوقف شود و عقب‌ماندگی کاهش نیابد، احتمال گیر کردن روی پیام یا وابستگی بیرونی را بررسی کنید. افزایش منابع بدون دیدن محل انتظار ممکن است هیچ اثری نداشته باشد.
برای آماده‌سازی عملیات، بازتخصیص پارتیشن، راه‌اندازی دوباره مصرف‌کننده و بازیابی از موقعیت قدیمی را جدا تمرین کنید. خروجی تمرین باید نشان دهد گزارش‌ها یا پایگاه داده مقصد پس از تکرار خواندن خراب نمی‌شوند. همچنین مدت نگهداری باید از بیشترین توقف قابل تحمل مصرف‌کننده بیشتر باشد؛ داده‌ای که از منبع حذف شده با جلو بردن موقعیت قابل بازیابی نیست. این تصمیم را با نیاز بازیابی و هزینه ذخیره‌سازی هماهنگ کنید و آن را صرفاً به مقدار پیش‌فرض واگذار نکنید.
تمرین بازسازی یک نمای موجودی
برای تمرین، سه کالا و چند تغییر وضعیت برای هر کدام تولید کنید. در مصرف‌کننده، یک جدول محلی با کلید کالا و آخرین مقدار نگه دارید و شناسه پیام پردازش‌شده را برای تشخیص تکرار ثبت کنید. ابتدا همه پیام‌ها را بخوانید و نتیجه نهایی را با فهرست مورد انتظار مقایسه کنید. سپس وضعیت محلی را پاک کنید و از موقعیت آغازین مناسب دوباره بخوانید. اگر نتیجه دوم متفاوت است، پیش از بررسی سرعت، قرارداد ترتیب و نحوه اعمال به‌روزرسانی را اصلاح کنید.
در مرحله بعد، یک پیام حذف برای کالای آزمایشی وارد کنید و بررسی کنید که نمای محلی آن را به شکل مورد انتظار حذف می‌کند. داده آزمایش باید از داده واقعی جدا باشد تا تکرار خواندن اثر تجاری ناخواسته نسازد. همچنین در گزارش بنویسید آیا هدف بازسازی آخرین وضعیت بوده یا بازسازی همه رخدادها؛ این دو معیار آزمون یکسان نیستند. برای مشاهده رفتار فشرده‌سازی، زمان و تنظیمات محیط را ثبت کنید و انتظار حذف فوری رکوردهای قدیمی نداشته باشید.
در پایان، مصرف‌کننده را برای مدت محدود متوقف کنید و پس از شروع دوباره، زمان رسیدن به وضعیت جاری را اندازه بگیرید. تعداد پیام‌های دوباره پردازش‌شده، خطاهای ساختار و نتیجه نهایی را کنار هم گزارش کنید. این تمرین کوچک، تفاوت میان سلامت خوشه، پیشرفت موقعیت خواندن و صحت خروجی تجاری را به شکل ملموس نشان می‌دهد و مبنای مناسبی برای آزمون‌های بزرگ‌تر می‌سازد.
