এই সিরিজের পिछলা আর্টিকেলে আমরা দেখেছিলাম যে Solid Queue একটি অত্যন্ত ভালো পছন্দ যদি আপনার ব্যাকগ্রাউন্ড জব প্রসেস করার জন্য একটি সিস্টেম দরকার হয়। এটি এক্সটার্ন্যাল ডিপেন্ডেন্সি মিনিমাইজ করে — Redis দরকার নেই! — সব জব আপনার ডাটাবেসে স্টোর করে। তারপরও, এটি অবিশ্বাস্যভাবে পারফরম্যান্ট।
কিন্তু শুধু পারফরম্যান্ট হওয়া প্রোডাকশন-রেডি ব্যাকগ্রাউন্ড জব সিস্টেমের জন্য পর্যাপ্ত নয়। Rails ডেভেলপাররা বছরের পর বছর একাধিক ফিচার এক্সপেক্ট করছে। আমরা শুধু জব এনকিউ করে ব্যাকগ্রাউন্ডে রান করাতে চাই না। আমরা জব শিডিউল করতে চাই, রিকারিং শিডিউলে রান করতে চাই, এবং আমরা এমনকী কতগুলো জব একসাথে রান করতে পারে সেটি লিমিট করতে চাই। আমরা আরও ফিচার চাই!
আশ্চর্য করক, Solid Queue সেই সব ফিচার আউট-অফ-দ-বক্স প্রদান করে। চলুন Solid Queue-র আরও গভীরে उतরি এবং শিখি কিভাবে সেটি সম্ভব!
Ruby on Rails-এ Solid Queue-র সাথে জব শিডিউলিং
প্রথমে, একটি ছোট রিক্যাপ। Solid Queue আপনার ডাটাবেস ব্যবহার করে — এবং শুধু আপনার ডাটাবেস — জব ডেটা স্টোর করতে। যা কিছু এটি করে সেটি এক ডাটাবেস টেবিল বা অন্যটির দ্বারা ব্যাকড। জব শিডিউল করা — অর্থাৎ, ভবিষ্যতে কোনো নির্দিষ্ট সময়ে রান করার জন্য জব ডেজিগনেট করা — সেটিও অপরিবর্তিত। যেকোনো শিডিউলড জব solid_queue_scheduled_executions-এ স্টোর হয়।
এই টেবিলটি solid_queue_ready_executions টেবিলের সাথে প্রায় একই। একমাত্র পার্থক্য হলো scheduled_at কলামের যোগফল, যা আমাদের বলে একটি শিডিউলড জব কখন এক্সিকিউট হওয়া উচিত। একটি জব শিডিউল করলে কী হয় তা দেখে নিশ্চিত হই।
সেখানে কোনো আশ্চর্য নেই। Solid Queue solid_queue_scheduled_executions টেবিলে একটি নতুন রো যোগ করে, যেটি আমাদের আশা করা ডেটা ধারণ করে। কিন্তু কিভাবে আমরা এখান থেকে আসলে ঠিক সময়ে একটি জব রান করাতে পারি?
আমাদের একটি প্রসেস দরকার যা solid_queue_scheduled_executions টেবিলকে কন্টিনিউয়াসলি 폴 করবে। সেই প্রসেসটি ডিসপ্যাচার (Dispatcher) নামে ডাকা হয়, এবং এটি শিডিউলড জবকে ঠিক সময়ে এক্সিকিউট করার জন্য দায়ী। এটি Solid Queue শুরু হলে শুরু হয় — কোনো অতিরিক্ত কনফিগারেশন দরকার নেই। যাইহোক, প্রয়োজনে আপনি শুধু ডিসপ্যাচার প্রসেস শুরু করতে পারেন Solid Queue-কে একটি নির্দিষ্ট কনফিগারেশন দিয়ে রান করে।
আপনি যদি চিন্তা করছেন ডিসপ্যাচার প্রসেস কীভাবে সুপারভাইজড হয়, সেটি সরাসরি Supervisor-র দায়িত্ব। এটি Solid Queue-এর ভিতরে যেকোনো রানিং প্রসেস ট্র্যাক করে, যার মধ্যে রয়েছে ওয়ার্কার প্রসেস এবং ডিসপ্যাচার।
তাহলে, ডিসপ্যাচার আসলে কীভাবে কাজ করে? এটি একটি poll মেথড ডিফাইন করে যা একটি লুপের মধ্যে কল হয় শিডিউলড জব চেক করার জন্য কন্টিনিউয়াসলি। পোলিং কোড বেশ কিছু ক্লাস এবং মডিউলে ছড়িয়ে আছে, কিন্তু ভাবাল সিম্প্লিফাইড ফর্মে, এটি এমন দেখায়:
'রেডি' শিডিউলড এক্সিকিউশন রিট্রিভ করার কোয়েরি সিম্পল।
তাহলে, অতীতে scheduled_at 가진 যেকোনো শিডিউলড জব ডিসপ্যাচ করার জন্য রেডি। পার্ট-একে আমরা যেভাবে কভার করেছিলাম, Solid Queue একটি জব ডিসপ্যাচ করলে, এটি একটি ReadyExecution রেকর্ড তৈরি করে এবং সংশ্লিষ্ট ScheduledExecution রেকর্ডটি ডিস্ট্রয় করে। ReadyExecution রেকর্ডটি তখন সাধারণ ওয়ার্কার প্রসেস দ্বারা পিক আপ করা হয়, এবং সংশ্লিষ্ট জব রান করে।
এতক্ষণ পর্যন্ত ভালো। শিডিউলড জব الحقيقيতে 그렇게 জটিল নয়! চলুন কিছু আরও জটিল দেখি: রিকারিং টাস্ক।
রিকারিং টাস্ক
রিকারিং টাস্ক ব্যাকগ্রাউন্ড জব প্রসেসরের জন্য একটি প্রায়শই অনুরোধকৃত ফিচার। সহজ কথায়, সেগুলো হলো ব্যাকগ্রাউন্ড জব যা একটি রিকারিং শিডিউলে রান করা উচিত। সেগুলো ক্রন জবের মতো যেহেতু আপনি একটি শিডিউল ডিফাইন করেন (যেমন প্রতি পাঁচ মিনিটে, প্রতিদিন দুপুরে ১২টা, ইত্যাদি) কাজ করার জন্য।
Solid Queue-এ, আপনি আপনার রিকারিং জব config/recurring.yml ফাইল ব্যবহার করে কনফিগার করেন। উদাহরণস্বরূপ, যদি আমরা চাই CleanupData জব প্রতিদিন দুপুরে ১২টা রান করানো, তাহলে আমরা এভাবে করব।
Solid Queue Fugit ব্যবহার করে শিডিউল এক্সপ্রেশন পার্স করতে, তাই মানব-পঠনযোগ্য শিডিউল যেমন 'every day at noon' অনুমোদিত। শিডিউলড টাস্ক ব্যবহার করার সময়, আপনি রান করানোর জন্য জব ক্লাস এবং যেকোনো জব আর্গুমেন্ট ডিফাইন করেন। عالی SolidQueue রিকারিং টাস্ক ReadMe আরও বিস্তারিত জানकारी দেয়। আমরা এখানে এটিকে কীভাবে কাজ করে তা শিখতে আছি, তাই আও আও দেখি।
রিকারিং টাস্ক RecurringTask মডেল দ্বারা রিপ্রেজেন্ট করা হয়, যেটি একটি সংশ্লিষ্ট solid_queue_recurring_tasks টেবিল দ্বারা ব্যাকড। সেখানে কলামগুলো কনফিগারেশন ফাইলে উপলব্ধ ফিল্ডের সাথে মিলে যায়।
SolidQueue শুরু করলে, রিকারিং টাস্ক রেকর্ড আপনার রিকারিং টাস্ক কনফিগারেশন ফাইলের অনুযায়ী তৈরি হয়। সঠিক সময়ে জব তৈরি করার জন্য, আমাদের একবার আবার একটি নতুন প্রসেস দরকার — এইবার বলা হয় Scheduler। Scheduler ডিসপ্যাচারের একটি সিবলিং যেটি আমরা ইতিমধ্যে জানি। এটি почти একইভাবে কাজ করে: Solid Queue শুরু হলে একটি নতুন প্রসেস স্পিন আপ হয়, এবং এই প্রসেস একটি এন্ডলেস লুপ রান করে। Scheduler এবং Dispatcher-এর পার্থক্য হলো সেই লুপের ভিতরে কী ঘটে। ডিসপ্যাচার যেখানে solid_queue_scheduled_executions টেবিল কোয়েরি করে, সিডিউলার solid_queue_recurring_tasks কোয়েরি করে — এবং সঠিক সময়ে জব শিডিউল করে। তাহলে, সিডিউলার কীভাবে সঠিক সময়টি জানে, এবং সঠিক জব কখন শিডিউল করবে?
उस প্রশ্নের উত্তর জানতে, আমাদের ইমপ্লিমেন্টেশনকে নিকটে থেকে পরীক্ষা করতে হবে। সিডিউলার ক্লাস একটি নতুন RecurringSchedule অবজেক্ট তৈরি করে যা একটি schedule মেথড ডিফাইন করে। সেই মেথডটি প্রতিটি শিডিউলড টাস্কের জন্য বারবার কল হয়। এখানে একটি সিম্প্লিফাইড ভার্সন:
এই কোডটি খুলে ফেলি। Solid Queue Concurrent::ScheduledTask ব্যবহার করে (concurrent-ruby লাইব্রেরি থেকে) একটি নতুন থ্রেড স্পান করতে। সেই থ্রেডটি রিকারিং টাস্কের শিডিউল দ্বারা নির্দিষ্ট সময়ে রান করার জন্য শিডিউল করা হয়। যখন সেই থ্রেড রান করে, এটি প্রথমে রিকারসিভলি অন্য একটি থ্রেড স্পান করে পরবর্তী রিকারিং টাস্ক শিডিউল করার জন্য। তারপর, এটি 'কারেন্ট' শিডিউলড জবটি এনকিউ করে।
একটি সিম্পল রিকারিং টাস্কের উদাহরণ দেখি সেটি বুঝতে।
যদি আমরা Solid Queue ৮:৩০-এ শুরু করি, তবে schedule মেথডের ভেরিয়েবলগুলো নিচের মান গুলো অ্যাসাইন করা হয়। শব্দশই নয়, মাইন্ড ইউ। আমরা খুব সিম্প্লিফাই করছি।
তাহলে, আমাদের ব্যাকগ্রাউন্ড থ্রেডটি ৩০ মিনিট পর থেকে রান করার জন্য শিডিউল করা হয়, যেটি ৯:০০। যখন সেই সময় আসে, ব্যাকগ্রাউন্ড থ্রেড এক্সিকিউট হয়। এটি thread_task.enqueue(at: 9:00) রান করে — তাই CleanupData-এর একটি ইনস্ট্যান্স এক্সিকিউশনের জন্য কিউড হয়। এটি রিকারসিভলি নিজেকেই কল করে thread_schedule.schedule 통해서। যেহেতু এখন ৯:০০, এই ইনভোকেশনের জন্য ভেরিয়েবলগুলো পরিবর্তিত হয়েছে।
তাহলে, ব্যাকগ্রাউন্ড থ্রেড আবার ১০:০০-এ রান করার জন্য শিডিউল করা হয়, এবং সাইকেলটি চলতে থাকে। আপনি চিন্তা করতে পারেন যদি সিডিউলিং থ্রেডটি মরে যায়, উদাহরণস্বরূপ একটি রি-ডিপ্লয় বা সিস্টেম ক্র্যাশের время। কি সেটি আপনার শিডিউল বিগিয়ে দেবে? خوشবর, উত্তর হ'ল না। ক্রন শিডিউল স্ট্যাটিক। 'Every Hour' মতো এক্সপ্রেশন সবসময় ১০:০০, ১১:০০, ১২:০০, ইত্যাদি রেজলভ করে, যেহেতু Solid Queue কখন শুরু হয়েছে সেটা নির্বিশেষে। সিডিউলিং থ্রেডে যেকোনো ইন্টারাপশন সেটাকে পরিবর্তন করে না।
এখানে কিছু অন্য ইমপ্লিমেন্টেশন ডিটেইলস দেওয়া হলো जिनেগুলো জানা উচিত। প্রথমে, রিকারিং টাস্কের পরবর্তী ঘটনা শিডিউল করার প্যাটার্ন এটি এক্সিকিউট করার আগে GoodJob-র দ্বারা অনুপ্রাণিত। দ্বিতীয়, RecurringTask.enqueue আপনার আশা অনুযায়ী একটি নতুন Job এবং ReadyExecution রেকর্ড তৈরি করে না। বরং, এটি আরও একটি রেকর্ড তৈরি করে, অর্থাৎ RecurringExecution।
এই রেকর্ডটি একমাত্র রিকারিং জব একাধিকবার এক্সিকিউট হওয়া থেকে বাঁচাতে। এটিতে task_key এবং run_at উপরে একটি ইনডেক্স রয়েছে ইউনিক কনস্ট্রেইন্টসহ সেই উদ্দেশ্যে। একটি RecurringTask শুধু কিউড হয় যদি একই সময় এবং একই জবের জন্য কোনো পূর্বের RecurringExecution নেই।
সতর্ক পাঠকরা লক্ষ্য করবেন এই কোড স্নিপেটটি Solid Queue-এ একটি সীমাবদ্ধতা নির্দেশ করছে। অর্থাৎ, যদি আপনি Solid Queue-কে আপনার ক্রন-স্টাইল টাস্ক রান করার ব্যাকএন্ড হিসেবে ব্যবহার না করেন — হ্যাঁ, আপনি সেটা করতে পারেন — Solid Queue গ্যারান্টি দিতে পারবে না যে রিকারিং জব শুধু একবার এনকিউড হবে। আপনি যদি এমন পরিস্থিতিতে পড়েন, তবে সেটি সম্পর্কে সচেতন থাকা উচিত।
আপনি আরও চিন্তা করতে পারেন সিডিউলার প্রসেস মরলে বা কিল হয়ে গেলে কী হবে — উদাহরণস্বরূপ, একটি ডিপ্লয়মেন্টের সময়। যেহেতু রিকারেন্স একটি থ্রেড দ্বারা ম্যানেজড, কি থ্রেডটি কিল করলে শিডিউল ভাঙাবে? خوشবর, সেটি लेकर উত্তরটিও না।
কনকারেন্সি কন্ট্রোল
চলুন Solid Queue-এর একটি চূড়ান্ত ফিচার দেখি, অর্থাৎ কনকারেন্সি কন্ট্রোল। কখনও কখনও, আপনি চাইবেন একটি নির্দিষ্ট ধরণের জব কতগুলো একসাথে রান করতে পারে সেটি লিমিট করা। আপনি Solid Queue-তে limits_concurrency ব্যবহার করে সেটা করতে পারেন।
এখানে, আমরা SolidQueue-কে বলছি প্রতিটি ইউজারের জন্য MyJob-র সর্বোচ্চ একটি ইনস্ট্যান্স রান করাও। কনফিগারেশনটি বিস্তারিত দেখি।
to: আপনি কতগুলো জব একসাথে রান করতে চান তার সর্বোচ্চ সংখ্যা।key: একটি রিকোয়ার্ড আর্গুমেন্ট যা ডেজিগনেট করে কোন জবগুলো একসাথে লিমিট করা উচিত। আমাদের উদাহরণে, একই ইউজার আইডি 가진 জবগুলো একটি কনকারেন্ট এক্সিকিউশনে লিমিটেড। আপনি যেকোনো জব আর্গুমেন্টkeyহিসেবে ব্যবহার করতে পারেন, কিন্তু কনস্ট্যান্ট যেমন স্ট্রিং বা সিম্বলও অনুমোদিত।duration: সর্বোচ্চ সময় য avs Solid Queue কনকারেন্সি গ্যারান্টি দিতে পারে একটি জব এনকিউড হওয়ার পরে। আপনার জব আপনার সেট করা সময়ের চেয়ে বেশি সময় চলে তবে, কনকারেন্সি কন্ট্রোল প্রয়োগ হবে না এবং জবগুলো ওভারল্যাপ হতে পারে। পরে শিখব কেন!group: আপনি এই অপশনটি ব্যবহার করতে পারেন বিভিন্ন জব ক্লাস জুড়ে কনকারেন্সি লিমিট করতে।
আরও জানতে চাইলে, আমি আপনাকে কনকারেন্সি কন্ট্রোল ডকুমেন্টেশনে রেফার করছি। কনকারেন্সি কন্ট্রোলস সহজে Solid Queue-র সবচেয়ে সোফিস্টিকেটেড ফিচার। যদি শিডিউলড টাস্ক ইতিমধ্যে আপনার মাথা ঘুরিয়ে দিয়েছে, তবে এই ফিচার কীভাবে কাজ করে সেটা শিখলে নিশ্চিতভাবেই ঘুরে যাবে।
বেসিক্স দিয়ে শুরু করি। Solid Queue-এর অন্যান্য ফিচারের মতো, কনকারেন্সি কন্ট্রোলও বিভিন্ন মডেল এবং তাদের সংশ্লিষ্ট ডাটাবেস টেবিল দ্বারা ব্যাকড। দুটি যা আপনাকে különভাবে জানতে হবে সেগুলো হলো Semaphore এবং BlockedExecution।
পहলে Semaphore দেখি। নামের ইঙ্গিত অনুযায়ী, এটি কাউন্টিং সেমাফোর প্যাটার্নের একটি ইমপ্লিমেন্টেশন। যখনই Solid Queue limits_concurrency সহ একটি জব এনকিউ করে, এটি প্রথমে একটি সেমাফোর লক অ্যাকোয়ার করার চেষ্টা করে একটি কনকারেন্সি কী বেসড অন। এই কনকারেন্সি কী limits_concurrency-এ পাস করা আর্গুমেন্টের উপর ভিত্তি করে, অর্থাৎ জব ক্লাস, কী, এবং গ্রুপ নাম — যদি কোনো দেওয়া থাকে। যদি সেমাফোর উপলব্ধ থাকে, জবটি এনকিউ হয়। যদি না হয়, একটি BlockedExecution রেকর্ড তৈরি হয়।
সেমাফোরের একটি value থাকে একাধিক কনকারেন্ট জব সাপোর্ট করার জন্য। আপনি এটিকে সেমাফোরের বাকি ক্যাপাসিটি হিসেবে ভাবতে পারেন। একটি সেমাফোর অ্যাকোয়ার করা মানে সেই ভ্যালু ডিক্রিমেন্ট করা, এবং রিলিজ করা মানে ইনক্রিমেন্ট করা। একটি সেমাফোর অনুপলব্ধ মाना হয় একবার এর ভ্যালু শূন্য হলে। একটি সিম্পল জবের জন্য লকিং মেকানিজম কীভাবে কাজ করে তার উদাহরণ দেখি।
দেখি কী হয় যদি আমরা এই জবকে একাধিকবার সাকসেসিভলি এনকিউ করার চেষ্টা করি।
MyJob-র প্রথম ইনস্ট্যান্স এনকিউ হয়। কোনো সেমাফোর নেই, তাই একটি তৈরি হয়। এর ইніশিয়াল ভ্যালুlimit - 1। যেহেতু আপনার লিমিট তিন, সেমাফোরের ইনীশিয়াল ভ্যালু দুই।MyJob-র দ্বিতীয় ইনস্ট্যান্স এনকিউ হয়। Solid Queue সেই জবের জন্য একটি লক অ্যাকোয়ার করার চেষ্টা করে। জবটি এনকিউ হতে পারে কারণ ভ্যালু দুই, যা শূন্যের চেয়ে বড়। সেমাফোরের ভ্যালু ডিক্রিমেন্ট হয়ে এক হয়ে যায়।- আমাদের জবের তৃতীয় ইনস্ট্যান্স এনকিউ হয়। আমরা আগের মতো একই প্রসিডিউর রিপিট করি। সেমাফোরের ভ্যালু এখন শূন্য।
MyJob-র চতুর্থ ইনস্ট্যান্স এনকিউ হয়। সেমাফোর অ্যাকোয়ার ফেল করে কারণ এর ভ্যালু এখন শূন্য। জবের জন্য একটিBlockedExecutionরেকর্ড তৈরি হয়।- আমাদের জবের প্রথম ইনস্ট্যান্স ফিনিশ হয়। যখন এটি ফিনিশ হয়, এটি সেমাফোর রিলিজ করে, তাই সেমাফোর ভ্যালু আবার এক হয়ে যায়।
- ফিনিশ হওয়ার সময়, প্রথম জব ইনস্ট্যান্স একটি মেথড কল করে কোনো ব্লকড জব রিলিজ করতে।
MyJob-র চতুর্থ ইনস্ট্যান্স রিলিজ হয় এবং আবার লক অ্যাকোয়ার করার চেষ্টা করে। সেমাফোর ভ্যালু এক, তাই লক অ্যাকোয়ার করা যায় এবং ব্লকড জব কিউড হয়। সেমাফোর ভ্যালু এখন শূন্য।
এক জব ফিনিশ হলে সেমাফোর রিলিজ করার কোড সহজ।
এখনও একটি ডিটেইল বাকি আছে যা আমরা ছোঁয়া নাই। সেমাফোরের এক্সপায়ারি ডেট কেন থাকে, এবং limits_concurrency ব্যবহার করার সময় duration সেট কেন দরকার?
চলুন বিবেচনা করি কী হয় যখন একটি জব তার সেমাফোর রিলিজ না করেই ক্র্যাশ করে — উদাহরণস্বরূপ, যখন সেই জব প্রসেস করার ওয়ার্কার মরে যায়। যদি না আমরা সেমাফোর ক্লিন আপ করার কিছু মেকানিজম অ্যাড করি, সেই জব যা লক ধরে রেখেছে সেটি চিরকাল ধরে রাখবে। সেরা কেসে, এটি চিরকাল অন্য জবগুলো প্রসেস হতে ব্লক করবে।
সেমাফোরের এক্সপায়ারি থাকে জব ডেফিনিশনে দেওয়া duration-র সাথে মিলে যেতে, যাতে সেটি না ঘটে। যদি একটি সেমাফোর এক্সপায়ার হয় — যেটি হয় যদি কোনো জব এনকিউড না হয় — সেমাফোরটি ডিস্ট্রয় করা হবে। আমরা ইতিমধ্যে জানি সেই প্রসেসের জন্য দায়বদ্ধ কে — সেটি আমাদের বন্ধু, Dispatcher। এটি ConcurrencyMaintenance ক্লাস ইনস্ট্যানশিয়েট করে, যা দুটি কাজ করে:
- প্রথম, যেকোনো এক্সপায়ারড সেমাফোর রিমুভ করে।
- দ্বিতীয়, চেক করে কোনো ব্লকড জব আছে কিনা এবং সেগুলো রিলিজ করে।
জবগুলো এক এক করে রিলিজ করা হয়, তাই কনকারেন্সি লিমিট এখনও लागু থাকবে। তবে, বিবেচনা করুন কী হয় যদি আপনার জব দেওয়া duration-র চেয়ে বেশি সময় চলে। সেক্ষেত্রে, সেমাফোর ক্লিন আপ হবে, যদিও জবটি চলতে থাকবে। যদি অন্য একটি জব তখন এনকিউড হয়, তবে সেগুলো ওভারল্যাপ করবে।
AppSignal-র সাথে Rails-এ Solid Queue মনিটরিং
যে রকম আমরা स्थापন করেছি, Solid Queue অনেক কিছু করতে পারে। কিন্তু এই সব মুভিং পার্টসহ, মনিটরিং জরুরি। خوشবর, AppSignal Solid Queue-এর জন্য বিল্ট-ইন সাপোর্ট দেয়, রেডি-মেড ড্যাশবোর্ডসহ জব এক্সিকিউশন টাইম, থ্রুপুট, এবং ফেইলার রেটের জন্য। শুধু আপনার Rails অ্যাপ্লিকেশনে AppSignal ইনস্টল করুন, এবং আপনি 準備完了।
AppSignal আপনার Solid Queue ব্যবহার অটোমেটিক্যালি ডিটেক্ট করবে এবং একটি এক্টিভ জব ড্যাশবোর্ড তৈরি করবে যেটি গুরুত্বপূর্ণ মেট্রিক্সের জন্য গ্রাফ ধারণ করে, যেমন এরর রেট এবং থ্রুপুট।
যদি আপনি কখনও জব মিসবিহেভ করতে দেখেন — হয় কারণ সেগুলো ধীরে চলে বা অনেক এরর আছে — সেগুলোকে একটি স্ট্যাটাস এবং অ্যাসাইনি দিন ইফেক্টিভলি সমস্যা সমাধান করার জন্য।
জাহিরانه, আপনাকে সারাদিন ড্যাশবোর্ড তাকিয়ে থাকতে হবে না সমস্যা বুঝতে। AppSignal Alerts আপনার পাশে আছে। শুধু জব মেট্রিক্সের জন্য একটি নতুন অ্যালার্ট তৈরি করুন, যেমন ফেইলার রেট এবং জব ডিউরেশন, এবং আপনি সেট।
Solid Queue আপনার অ্যাপ্লিকেশনে শক্তিশালী জব প্রসেসিং যোগ করার জন্য অসাধারণ বিনা যেকোনো ঝামেলা। AppSignal মোনিটরিং-এ সেটি করে!
উপসংহার
Solid Queue-এর উন্নত ফিচারগুলোর আমাদের এক্সপ্লোরেশনে আমরা অনেক জমিন কভার করেছি। শিডিউলড জব থেকে জটিল ডিপেন্ডেন্সি চেইন পর্যন্ত, প্রতিটি ফিচার পার্ট-একরে আমরা যে স olid ফাউন্ডেশন নিয়ে আলোচনা করেছিলাম সেটির ওপর নির্মিত। আমরা যা দেখেছি, একটি জব প্রসেসিং ব্যাকএন্ড তৈরি করা সহজ নয়। কিন্তু Solid Queue সোর্স কোড এবং এর কাজকর্মে গভীরে ডুব 마রে, আমরা একটি বোঝাপড়া এবং কিছু প্রশংসা অর্জন করেছি চ্যালেঞ্জগুলো নিয়ে।
যাহোক, Solid Queue Rails ইকোসিস্টেমের একটি চমৎকার সংযোজন, এর عالی ডাটাবেস ডিজাইন এবং প্রসেস কোঅর্ডিনেশনের কারণে। এটি আপনার প্রয়োজনীয় টুলগুলো প্রদান করে তার কোর প্রমিশ বজায় রেখে: সিম্পলিসিটি এবং রিলায়বিলিটি, এক্সটার্ন্যাল ডিপেন্ডেন্সি ছাড়া।
হ্যাপি কোডিং!
