লাভ:
- গতি সীমা (RPM/ITPM/OTPM) এবং 429 ত্রুটি ব্যাখ্যা করতে পারে
- সূচকীয় ব্যাকঅফ প্রয়োগ করে এবং পুনরায় চেষ্টা করার পরে পুনরায় চেষ্টা করে
- সাধারণ HTTP ত্রুটি কোডগুলি সঠিকভাবে শ্রেণীবদ্ধ করে এবং পরিচালনা করে (400/401/429/500/529)
একটি উত্পাদন পরিবেশে, কোনও API সর্বদা পুরোপুরি প্রতিক্রিয়া জানায় না। কখনও কখনও আপনি খুব দ্রুত অনুরোধ পাঠান এবং সীমা আঘাত; কখনও কখনও সার্ভার সাময়িকভাবে ব্যস্ত থাকে; কখনও কখনও আপনার অনুরোধ প্রথম থেকেই ভুল হয়। একটি অপেশাদার প্রচেষ্টা থেকে একটি কঠিন একীকরণকে যা আলাদা করে তা হল এটি এই পরিস্থিতিগুলি ভবিষ্যদ্বাণীমূলকভাবে এবং স্বয়ংক্রিয়ভাবে পরিচালনা করে। এই ইউনিটে আপনি হারের সীমা (RPM/ITPM/OTPM), 429 ত্রুটি, সূচকীয় ব্যাকঅফের সাথে পুনরায় চেষ্টা করুন এবং সাধারণ HTTP ত্রুটি কোডগুলির সঠিক শ্রেণিবিন্যাস সম্পর্কে শিখবেন। লক্ষ্য: এমন একটি প্রবাহ তৈরি করা যা এত শক্তিশালী যে একজন ব্যবহারকারী কখনই এটি লক্ষ্য করবেন না।
গতি সীমা কি?
একটি নির্দিষ্ট সময়ের মধ্যে একটি সুইচ কতটা কাজ করতে পারে তা প্রদানকারী সীমিত করে। এই সুরক্ষা; এটি অবকাঠামো এবং আপনাকে হঠাৎ খরচের বিস্ফোরণ থেকে রক্ষা করে। তিনটি সাধারণ ধরনের সীমা আছে:
- RPM (প্রতি মিনিটে অনুরোধ): প্রতি মিনিটে অনুরোধের সংখ্যা।
- ITPM (ইনপুট টোকেন পার মিনিট): ইনপুট টোকেন যা প্রতি মিনিটে প্রক্রিয়া করা যায়।
- OTPM (আউটপুট টোকেন পার মিনিট): আউটপুট টোকেন যা প্রতি মিনিটে তৈরি করা যায়।
আপনি যদি এই সীমাগুলির মধ্যে যেকোনো একটি অতিক্রম করেন, প্রদানকারী অনুরোধটি প্রত্যাখ্যান করে এবং একটি 429 ত্রুটি কোড ফেরত দেয়। সীমাগুলি সাধারণত আপনার অ্যাকাউন্ট স্তরের (স্তরের) উপর নির্ভর করে পরিবর্তিত হয় এবং সময়ের সাথে সাথে বাড়ানো হতে পারে।
টিপ: আপনি যখন প্রতিক্রিয়া শিরোনাম থেকে সীমার কাছাকাছি আসছেন তখন আপনি দেখতে পারেন। বেশিরভাগ প্রদানকারীই x-ratelimit-remaining-* এর মত হেডার সহ আপনার অবশিষ্ট কোটা রিপোর্ট করে। এই মানগুলি পর্যবেক্ষণ করা এবং সামনের ট্র্যাফিক থ্রোটল করা হল 429 না পেয়ে সমস্যা প্রতিরোধ করার সবচেয়ে পরিণত উপায়।
429 এবং এক্সপোনেনশিয়াল রিট্রেসমেন্ট
429 (দর সীমা) একটি অস্থায়ী এবং পুনরায় চেষ্টাযোগ্য ত্রুটি। সঠিক প্রতিক্রিয়া হল অনুরোধের জন্য কিছুক্ষণ অপেক্ষা করা এবং আবার চেষ্টা করা। কিন্তু একটি ধ্রুবক অপেক্ষা যথেষ্ট নয়; সবাই একই সময়ে আবার চেষ্টা করলে, সীমা আবার পৌঁছে যাবে। সমাধান হল সূচকীয় ব্যাকঅফ: প্রতিটি ব্যর্থ প্রচেষ্টার সাথে দ্রুত অপেক্ষার সময় বৃদ্ধি করা।
# এক্সপোনেনশিয়াল ব্যাকঅফ লজিক ট্রায়াল 1 → 429 → অপেক্ষা করুন 1 সেকেন্ড ট্রায়াল 2 → 429 → অপেক্ষা করুন 2 সেকেন্ড ট্রায়াল 3 → 429 → অপেক্ষা করুন 4 সেকেন্ড ট্রায়াল 4 → 429 → 8 সেকেন্ড অপেক্ষা করুন (+ ছোট র্যান্ডম "জিটার")... হাল ছেড়ে দিন এবং সর্বাধিক N ট্রায়ালের পরে রিপোর্ট করুন
এটিতে সামান্য এলোমেলোতা (জিটার) যোগ করা একই সময়ে পুনরায় চেষ্টা করার সময় অনুরোধগুলিকে সংঘর্ষে বাধা দেয়। উপরন্তু, 429 প্রতিক্রিয়া প্রায়ই একটি 'পুনরায় চেষ্টা-পরে' শিরোনাম বহন করে: "এই অনেক সেকেন্ডের মধ্যে আবার চেষ্টা করুন"। এই শিরোনামকে সম্মান করা অন্ধভাবে অপেক্ষা করার চেয়ে আরও সঠিক।
সতর্কতা: আপনি যখন একটি 429 পান, "আরো অনুরোধ পাঠিয়ে এটিকে বাধ্য করা" পরিস্থিতি আরও খারাপ করে তুলবে; সীমা পূর্ণ হতে থাকে এবং কোনো অনুরোধ আসে না। সঠিক প্রতিক্রিয়া হল পশ্চাদপসরণ, ত্বরণ নয়। সুসংবাদ: বেশিরভাগ অফিসিয়াল SDK স্বয়ংক্রিয়ভাবে 429 পুনরায় চেষ্টা করে এবং একটি ব্যাকঅফের সাথে সার্ভার ত্রুটি — ম্যানুয়ালি ইনস্টল করার আগে SDK-এর এই আচরণটি ব্যবহার করুন৷
HTTP ত্রুটি কোড শ্রেণীবদ্ধ করা
সব ভুল এক নয়। সমালোচনামূলক পার্থক্য: এটি কি আবার চেষ্টা করা যেতে পারে বা এটি একটি অনুরোধ/পরিচয় সমস্যা?
কোড
অর্থ
এটা আবার চেষ্টা করা যেতে পারে?
সঠিক প্রতিক্রিয়া
400
অবৈধ অনুরোধ (ফরম্যাট/প্যারামিটার ত্রুটি)
না
অনুরোধ সংশোধন করুন; আবার একই পাঠাবেন না
401
প্রমাণীকরণ ত্রুটি (কী অবৈধ/অনুপস্থিত)
না
কী/শিরোনাম ঠিক করুন
403
কোনো অনুমোদন নেই (মডেল/বৈশিষ্ট্যে কোনো অ্যাক্সেস নেই)
না
অনুমতি/স্কোপ চেক করুন
404
পাওয়া যায়নি (ভুল মডেল আইডি/এন্ডপয়েন্ট)
না
সঠিক মডেল আইডি/ঠিকানা
429
গতিসীমা ছাড়িয়ে গেছে
হ্যাঁ
রিট্রিট + রিট্রিট-আফটার
500
সার্ভার ত্রুটি
হ্যাঁ
পশ্চাদপসরণ সঙ্গে আবার চেষ্টা করুন
529
সার্ভার ওভারলোড
হ্যাঁ
পশ্চাদপসরণ সঙ্গে আবার চেষ্টা করুন
সুবর্ণ নিয়ম: 429, 500 এবং 529 অস্থায়ী; এটা প্রত্যাহার সঙ্গে আবার চেষ্টা করা হয়. 400, 401, 403, 404 হল অনুরোধ/পরিচয় সংক্রান্ত সমস্যা; আবার চেষ্টা করলে এটি সমাধান হবে না, এবং এটি প্রচেষ্টা নষ্ট করে। আপনার কোড এই দুটি গ্রুপের মধ্যে পার্থক্য করা আবশ্যক.
ধাপে ধাপে: টেকসই কল
- অনুরোধ জমা দিন. সফল হলে, চালিয়ে যান।
- ত্রুটি কোড শ্রেণীবদ্ধ করুন. এটা আবার চেষ্টা করা যেতে পারে?
- চেষ্টা করা হলে: পুনরায় চেষ্টা-পরবর্তী অনুসরণ করুন, সূচকীয় ব্যাকঅফ + জিটার প্রয়োগ করুন, সীমিত সংখ্যক বার চেষ্টা করুন (যেমন সর্বোচ্চ 5)।
- যদি চেষ্টা না করা হয়: ঠিক করুন (ফরম্যাট/কী) এবং বন্ধ করুন; লুপে একই ভুল অনুরোধের পুনরাবৃত্তি করবেন না।
- হাল ছেড়ে দেওয়ার কথা ভাবুন। n প্রচেষ্টার পরেও ব্যর্থ হলে, ব্যবহারকারীকে একটি ভদ্র বার্তা দেখান এবং ইভেন্টটি লগ করুন (ট্র্যাকিং ইউনিট 11)।
# জোরালো কল pseudo-codedene = 0repeat: response = request_at() if response.success: উত্তর দিন if response.code in [429, 500, 529] এবং চেষ্টা করুন < 5: wait = retry_after ?? (2^ট্রাই সেকেন্ড + জিটার) ঘুম (অপেক্ষা করুন); চেষ্টা করুন += 1; git আবার if response.code in [400, 401, 403, 404]: save_error(response); প্রত্যাবর্তন "অনুরোধ অবশ্যই ঠিক করতে হবে" ফেরত "স্থায়ী ত্রুটি, পরে চেষ্টা করুন"
# ব্যবহারকারীর প্রতি ভদ্র প্রতিক্রিয়া (যখন পুনঃপ্রয়াস শেষ হয়ে যায়) "আমি এই মুহূর্তে ব্যস্ত, আমি আপনার অনুরোধ প্রক্রিয়া করতে পারিনি। শীঘ্রই আবার চেষ্টা করুন, অথবা আমি আপনার অনুরোধ সংরক্ষণ করেছি, এটি প্রস্তুত হলে আমি আপনার কাছে ফিরে আসব।"
দুর্বল প্রম্পট / শক্তিশালী প্রম্পট (এখানে: ত্রুটি বার্তা ডিজাইন)
# দুর্বল (ব্যবহারকারীর কাছে কাঁচা ত্রুটি প্রদর্শন করে)"ত্রুটি 429: হার_সীমা_ত্রুটি"
# স্ট্রং (ব্যবহারকারী-বান্ধব, আশ্বস্তকারী, অ্যাকশন-পরামর্শকারী) "সিস্টেমে একটি অস্থায়ী যানজট ছিল। আমরা নিরাপদে আপনার অনুরোধ পেয়েছি এবং এটি স্বয়ংক্রিয়ভাবে আবার চেষ্টা করা হচ্ছে। যদি ফলাফল কয়েক সেকেন্ডের মধ্যে প্রদর্শিত না হয়, আপনি পৃষ্ঠাটি রিফ্রেশ করতে পারেন।"
শেষ ব্যবহারকারীর কাছে কাঁচা প্রযুক্তিগত ত্রুটি প্রকাশ করা উভয়ের বিশ্বাসকে ক্ষুন্ন করে এবং এটি একটি নিরাপত্তা দুর্বলতা হতে পারে। অভ্যন্তরীণভাবে ত্রুটিগুলি শ্রেণীবদ্ধ করুন এবং ব্যবহারকারীকে একটি শান্ত, কর্মমুখী বার্তা দিন; শুধু রেকর্ডের জন্য প্রযুক্তিগত বিশদ লিখুন।
তিনটি মিনি কেস
কেস 1 - ট্র্যাফিক বিস্ফোরণে নৌকা বিধ্বস্ত হয়েছে। প্রচারাভিযানের দিনে একটি গ্রাহক পরিষেবা বট 429টি বাড়তি ট্রাফিক পেয়েছে; কোডটিতে কোন পুনঃপ্রচেষ্টা ছিল না, প্রতিটি ত্রুটি সরাসরি ব্যবহারকারীর কাছে "ত্রুটি" হিসাবে প্রতিফলিত হয়েছিল। তারা সূচকীয় রিট্রেসমেন্ট + পুনরায় চেষ্টা-পরবর্তী যোগ করেছে; একই ট্র্যাফিকের সাথে, অনুরোধগুলি কয়েক সেকেন্ডের বিলম্বের সাথে পাস করা হয়েছে, ব্যবহারকারী কোনও ত্রুটি দেখতে পাননি।
কেস 2 — লুপে 400 চেষ্টা করা। একটি অবৈধ মডেল আইডির কারণে একটি ইন্টিগ্রেশন একটি 404 পেয়েছিল, কিন্তু সমস্ত ত্রুটিকে "ক্ষণস্থায়ী" হিসাবে বিবেচনা করছিল এবং একটি অসীম লুপে আবার চেষ্টা করছিল; লগ ফুলে ওঠে এবং অপ্রয়োজনীয় বোঝা তৈরি হয়। তারা ত্রুটি শ্রেণীবিভাগ যোগ করেছে: 404 স্থায়ী হিসাবে বিবেচিত হয়, লুপ বন্ধ করা হয় এবং মডেল আইডি সংশোধন করা হয়। পাঠ: প্রতিটি ভুল আবার চেষ্টা করবেন না।
কেস 3 - সামনে থেকে সীমা পরিচালনা করা। একটি ডেটা সমৃদ্ধকরণ কাজ ক্রমাগত 429 সীমাতে চলছিল। তারা এক্স-রেটলিমিট-বাকি হেডার অনুসরণ করে এবং কোটা অনুযায়ী ট্রাফিক থ্রোটল করে। তাই তারা কোনো 429 না নিয়ে সীমার ঠিক নিচে একটি অবিচলিত গতি রেখেছিল; কাজটি আরও অনুমানযোগ্য এবং দ্রুত সম্পন্ন হয়েছিল।
সাধারণ ভুল
- 429-এ গতি বৃদ্ধি: পরিস্থিতি আরও খারাপ করে তোলে; পশ্চাদপসরণ স্যুইচ.
- প্রতিটি ত্রুটি পুনরায় চেষ্টা করা: 400/401/404 স্থায়ী; আবার চেষ্টা করা একটি অপচয়.
- স্থির অপেক্ষা ব্যবহার করে: একটি সংঘর্ষ তৈরি করে; সূচক + জিটার ব্যবহার করুন।
- 'পুনরায় চেষ্টা-পরে' উপেক্ষা করা: প্রদানকারীর দ্বারা নির্দিষ্ট সময় মেনে চলা সবচেয়ে সঠিক।
- ব্যবহারকারীর কাছে অশোধিত ত্রুটি প্রকাশ করা: আস্থা নাড়ায়, দুর্বলতা তৈরি করে; ভিতরে শ্রেণীবদ্ধ করুন।
- সীমাহীন পুনঃপ্রচার: একটি উচ্চ সীমা সেট করুন (যেমন 5টি পুনঃপ্রচার); তারপর করুণাময়ভাবে ছেড়ে দিন।
গভীরতর: সারিবদ্ধ, সমগতি, এবং সার্কিট ব্রেকার
একক ইচ্ছার সহনশীলতা প্রথম ধাপ; প্রকৃত পরিপক্কতা হল সীমা অতিক্রম না করে বিপুল সংখ্যক অনুরোধ পরিচালনা করা। তিনটি ধারণা এখানে কার্যকর হয়।
সারি: আপনি অনুরোধগুলিকে অবিলম্বে না করে একটি নিয়ন্ত্রিত গতিতে পাঠানোর জন্য একটি সারিতে রেখেছিলেন৷ সারিবদ্ধ ট্র্যাফিকের আকস্মিক বিস্ফোরণকে মসৃণ করে: এমনকি যদি 1,000টি অনুরোধ একবারে আসে, তবে সারি সীমার কম হারে সেগুলিকে ছেড়ে দেবে। এইভাবে আপনি 429 প্রতিরোধ করেন, তাহলে আপনাকে এটি ঠিক করার বিষয়ে চিন্তা করতে হবে না।
সামঞ্জস্যের সীমা: আপনি একই সময়ে কতগুলি অনুরোধ "বাতাসে" আছে তা সীমাবদ্ধ করেন। সীমাহীন সমান্তরাল অনুরোধ দ্রুত RPM এবং TPM সীমা পূরণ করে। একটি যুক্তিসঙ্গত সঙ্গতি সিলিং (যেমন 10টির বেশি একযোগে অনুরোধ নয়) উভয়ই সীমা বজায় রাখে এবং সিস্টেমটিকে অনুমানযোগ্য করে তোলে।
সার্কিট ব্রেকার: যদি প্রদানকারী 500/529 ফেরত দিতে থাকে, প্রতিটা অনুরোধের চেষ্টা করার পরিবর্তে, আপনি কিছুক্ষণের জন্য "সার্কিট ভেঙ্গে ফেলুন" এবং অনুরোধটি কখনও না পাঠিয়ে দ্রুত ব্যর্থ হবেন। অপেক্ষা করার পর, আপনি সার্কিটটি আবার চালু করুন এবং চেষ্টা করুন। এই প্যাটার্নটি অস্থায়ী প্রদানকারীর ব্যর্থতার ক্ষেত্রে আপনার সিস্টেমকে ক্র্যাশ হতে বাধা দেয়।
একসাথে, এই তিনটি একক কলের পুনরায় চেষ্টা করার যুক্তির বাইরে সিস্টেম-স্তরের স্থিতিস্থাপকতা প্রতিষ্ঠা করে। একটি ছোট স্কেলে, SDK-এর স্বয়ংক্রিয় পুনরায় চেষ্টা যথেষ্ট; স্কেল বাড়ার সাথে সাথে সারিবদ্ধকরণ, সমগতি এবং সার্কিট ব্রেকার অপরিহার্য হয়ে ওঠে। তাদের সকলের একই সাধারণ লক্ষ্য রয়েছে: ব্যবহারকারীর কাছে একটি অস্থায়ী সমস্যাকে ক্র্যাশ হিসাবে নয়, কয়েক সেকেন্ডের অদৃশ্য বিলম্ব হিসাবে প্রতিফলিত করা।
সংক্ষেপে
গতি সীমা (RPM/ITPM/OTPM) অতিক্রম করলে 429 ফেরত আসে; এটি একটি অস্থায়ী ত্রুটি এবং পুনরায় চেষ্টা-পরবর্তী এবং সূচকীয় ব্যাকঅফ + জিটার ব্যবহার করে পুনরায় চেষ্টা করা হবে। 500 এবং 529 এছাড়াও অস্থায়ী; 400/401/403/404 একটি অনুরোধ/পরিচয় সমস্যা এবং আবার চেষ্টা করে সমাধান করা যাবে না। একটি শক্তিশালী প্রবাহ এই দুটি গ্রুপে ত্রুটিগুলিকে আলাদা করে, সীমিত সংখ্যক বার চেষ্টা করে, সামনে থেকে সীমা নিরীক্ষণ করে এবং ব্যবহারকারীকে শান্ত বার্তা দেখায়।
আবেদন টাস্ক
আপনার ইন্টিগ্রেশন বিবেচনা করুন. (1) আপনি যে ত্রুটি কোডগুলির সম্মুখীন হতে পারেন তার তালিকা করুন এবং সেগুলিকে "পুনরায় চেষ্টাযোগ্য/স্থায়ী"-এ আলাদা করুন৷ (2) আপনার সূচকীয় পুলব্যাক পরিকল্পনা লিখুন (প্রাথমিক হোল্ড, সহগ, ক্যাপ, জিটার)। (3) কিভাবে retry-after হেডার ব্যবহার করবেন তা উল্লেখ করুন। (4) পুনঃপ্রয়াস শেষ হয়ে গেলে ব্যবহারকারীর কাছে প্রদর্শিত ভদ্র বার্তাটি লিখুন।
চেকলিস্ট
- [ ] আমি RPM/ITPM/OTPM সীমা এবং 429 ব্যাখ্যা করতে পারি।
- [ ] আমি সূচকীয় পশ্চাদপসরণ + জিটার + পুনরায় চেষ্টা-পরবর্তী যুক্তি প্রয়োগ করতে পারি।
- [] আমি ত্রুটি কোডগুলিকে পুনরায় চেষ্টাযোগ্য/স্থায়ী হিসাবে শ্রেণীবদ্ধ করতে পারি।
- [ ] আমি জানি যে আমাদের প্রতিটি ভুলের চেষ্টা করা উচিত নয়।
- [ ] একটি কাঁচা ত্রুটির পরিবর্তে, আমি ব্যবহারকারীকে একটি শান্ত, কর্মমুখী বার্তা দেখাতে পারি৷