API-এর সাথে কাজ করার সময় অর্ডার ডুপ্লিকেট: কারণ ও সুরক্ষা
একটি কাজের পরে কেন ডুপ্লিকেট দেখা যায়
প্যানেলের মালিক একবার বোতাম চাপতে পারেন এবং একাধিক একই রকম অর্ডার দেখতে পারেন: সাবস্ক্রাইবার, ভিউ, রিঅ্যাকশন বা অন্য কোনো সেবার জন্য। সাধারণত সমস্যাটি ক্লিকের মধ্যে নয়, বরং ক্লায়েন্ট, API, ডেটাবেস এবং সরবরাহকারীর মধ্যবর্তী চেইনে।
সার্ভারের দৃষ্টিকোণ থেকে "একটি অনুরোধ" সবসময় একটি নয়। ক্লায়েন্ট উত্তর পায়নি, আবার পাঠিয়েছে, কিন্তু প্রথম অপারেশনটি ইতিমধ্যে সংরক্ষিত হয়ে গেছে। কখনও কখনও প্যানেলের ডেটাবেসে অর্ডার একবার তৈরি হয়, কিন্তু সরবরাহকারীর কাছে দুইবার যায়। এগুলো ভিন্ন পরিস্থিতি, এবং এগুলো ভিন্নভাবে ঠিক করা হয়।
টাইমআউট মানে এই নয় যে অর্ডার তৈরি হয়নি
সবচেয়ে সাধারণ কারণ হলো ক্লায়েন্ট সীমিত সময়ের জন্য উত্তর অপেক্ষা করে। সার্ভার অনুরোধ গ্রহণ করে, অর্ডার তৈরি করে, কিন্তু নির্ধারিত টাইমআউটের পরে উত্তর দেয়। ক্লায়েন্ট অপারেশনটিকে ব্যর্থ মনে করে এবং আবার পাঠায়।
ফলে প্রথম অর্ডার ইতিমধ্যে ডেটাবেসে আছে, এবং দ্বিতীয় অনুরোধ আরেকটি তৈরি করে। এটি বিশেষভাবে প্রায়ই ঘটে বাহ্যিক API-এর ধীর প্রতিক্রিয়া, ওভারলোডেড কিউ বা সার্ভিসগুলোর মধ্যে অস্থির সংযোগের সময়।
টাইমআউট শুধুমাত্র উত্তরের অনুপস্থিতি বোঝায়, অনুরোধ প্রক্রিয়াকরণের অনুপস্থিতি নয়।
ক্লায়েন্টের দিকে স্বয়ংক্রিয় পুনরাবৃত্তি
HTTP অনুরোধের জন্য লাইব্রেরি, ব্যাকগ্রাউন্ড টাস্ক এবং ইন্টিগ্রেশন সার্ভিসগুলো প্রায়ই স্বয়ংক্রিয়ভাবে অনুরোধ পুনরাবৃত্তি করে। কারণ হতে পারে সংযোগ ত্রুটি, সার্ভার প্রতিক্রিয়া কোড, নেটওয়ার্ক বিচ্ছিন্নতা বা অত্যধিক দীর্ঘ প্রতিক্রিয়া।
পুনরাবৃত্তি নিজেই উপকারী: এটি সাময়িক ব্যর্থতার সময় হারানো অর্ডারের সংখ্যা কমায়। এই পদ্ধতির অসুবিধা হলো — পুনরায় প্রক্রিয়াকরণ থেকে সুরক্ষা ছাড়া এটি নেটওয়ার্কের যেকোনো অস্থিরতাকে ডুপ্লিকেটে পরিণত করে।
- পুনরাবৃত্তি সাইটের কোড বা বটে চালু হতে পারে;
- কিউ টাস্কটি পুনরায় চালু করতে পারে;
- প্রক্সি বা ইন্টিগ্রেশন মডিউল অনুরোধ পুনরাবৃত্তি করতে পারে;
- অপারেটর ত্রুটির পরে ম্যানুয়ালি অর্ডার আবার পাঠাতে পারে।
পুনরাবৃত্ত অনুরোধ প্রথম উত্তরের আগে আসে
কখনও কখনও দুটি একই রকম অনুরোধ সত্যিই প্রায় একই সাথে API-তে পৌঁছায়। উদাহরণস্বরূপ, ব্যবহারকারী ফর্মটি দুইবার জমা দিয়েছেন, ফ্রন্টএন্ড বোতামটি ব্লক করেনি বা ব্যাকগ্রাউন্ড টাস্ক প্রথমটি শেষ হওয়ার আগে পুনরায় শুরু হয়েছে।
যদি হ্যান্ডলার প্রথমে অর্ডারের উপস্থিতি পরীক্ষা করে এবং তারপর এটি তৈরি করে, দুটি সমান্তরাল অপারেশন একই সাথে পরীক্ষায় উত্তীর্ণ হতে পারে। প্রত্যেকে দেখবে যে অর্ডার এখনও নেই, এবং প্রত্যেকে একটি নতুন রেকর্ড যোগ করবে।
এই পরিস্থিতিকে রেস কন্ডিশন বলা হয়। কোডে সাধারণ প্রাথমিক পরীক্ষা এটি থেকে সম্পূর্ণভাবে সুরক্ষা দেয় না। ডেটাবেস স্তরে সীমাবদ্ধতা ছাড়া পরীক্ষার অসুবিধা হলো — সমান্তরাল লোডে এটি ভেঙে পড়ে।
অর্ডার সংরক্ষিত হয়েছে, কিন্তু API উত্তর হারিয়ে গেছে
অনুরোধ কয়েকটি ধাপ অতিক্রম করে: সার্ভার ডেটা গ্রহণ করে, রেকর্ড তৈরি করে, কিউতে টাস্ক রাখে, উত্তর পাঠায়। যেকোনো ধাপের মধ্যে ব্যর্থতা সম্ভব। উদাহরণস্বরূপ, ডেটাবেস ইতিমধ্যে অর্ডার তৈরির নিশ্চিত করেছে, কিন্তু ক্লায়েন্টের কাছে উত্তর পাঠানোর আগে সংযোগ বিচ্ছিন্ন হয়েছে।
ক্লায়েন্ট জানে না অর্ডার গ্রহণ করা হয়েছে কিনা, এবং অপারেশনটি পুনরাবৃত্তি করে। পৃথক যাচাইকরণ ব্যবস্থা ছাড়া API অনুরোধটিকে নতুন হিসেবে গ্রহণ করে। লগে এটি প্রায়ই এমন দেখায় যেন সার্ভিস "নিজে" দুটি অর্ডার তৈরি করেছে, যদিও এর দুটি আগত অনুরোধ ছিল।
অর্ডার তৈরির জন্য আইডেম্পোটেন্ট কী
তৈরির অপারেশনের জন্য একটি অনন্য আইডেম্পোটেন্সি কী প্রয়োজন। ক্লায়েন্ট প্রথম পাঠানোর আগে এটি তৈরি করে এবং অর্ডারের প্যারামিটারসহ পাঠায়। টাইমআউট বা ত্রুটির কারণে পুনরাবৃত্তির সময় একই কী ব্যবহার করা হয়।
API প্রক্রিয়াকরণের ফলাফলের সাথে কী সংরক্ষণ করে। যদি ইতিমধ্যে পরিচিত কী সহ একটি অনুরোধ আসে, সার্ভার নতুন অর্ডার তৈরি করে না, বরং প্রথম অনুরোধের ফলাফল ফেরত দেয়: অর্ডারের আইডেন্টিফায়ার, এর স্ট্যাটাস বা আগে তৈরি ত্রুটি।
একটি কী একটি ব্যবসায়িক অপারেশনের সাথে মিলতে হবে, একটি HTTP সংযোগের সাথে নয়।
পদ্ধতির অসুবিধা হলো — কীগুলো সংরক্ষণ, নিয়ম অনুযায়ী পরিষ্কার এবং API-এর দিকে যাচাই করতে হয়। যদি প্রতিটি পুনরাবৃত্তিতে নতুন কী তৈরি হয়, সুরক্ষা কাজ করবে না। যদি বিভিন্ন অর্ডারের জন্য একটি কী ব্যবহার করা হয়, নতুন অপারেশনের কিছু অংশ ভুলভাবে প্রত্যাখ্যাত হবে।
অনন্যতা ডেটাবেস দ্বারা নিয়ন্ত্রিত হতে হবে
আইডেম্পোটেন্সি ডেটাবেসে অনন্যতার সীমাবদ্ধতা দিয়ে সম্পূরক করা ভালো। এর জন্য এমন একটি সমন্বয় বেছে নেওয়া হয় যা অর্ডারকে দ্ব্যর্থহীনভাবে বর্ণনা করে: ক্লায়েন্টের অভ্যন্তরীণ আইডেন্টিফায়ার, আইডেম্পোটেন্সি কী, সেবার ধরন এবং অন্যান্য প্রয়োজনীয় ক্ষেত্র।
ডেটাবেস দ্বিতীয় রেকর্ড প্রত্যাখ্যান করতে হবে, এমনকি যদি দুটি হ্যান্ডলার একই সাথে তৈরিতে পৌঁছায়। দ্বন্দ্বের পরে API বিদ্যমান অর্ডার ফেরত দেয়, ব্যাখ্যা ছাড়া ত্রুটি নয়।
কঠোর অনন্য সীমাবদ্ধতার অসুবিধা হলো — এটি শুধুমাত্র লিঙ্ক বা username-এর উপর তৈরি করা যায় না। ক্লায়েন্ট সচেতনভাবে একই চ্যানেলে একটি সেবা কয়েকবার অর্ডার করতে পারে। অত্যধিক বিস্তৃত সীমাবদ্ধতা স্বাভাবিক পুনরায় ক্রয় ব্লক করবে।
কিউ একটি টাস্ক একাধিকবার সরবরাহ করতে পারে
টাস্ক কিউগুলো প্রায়ই "অন্তত একবার সরবরাহ" নীতিতে কাজ করে। যদি ওয়ার্কার টাস্কটি প্রক্রিয়া করে কিন্তু এর সম্পাদন নিশ্চিত করতে না পারে, কিউ একই টাস্ক অন্য ওয়ার্কারকে পুনরায় দিতে পারে।
কিউয়ের জন্য এটি টাস্ক হারানো না যাওয়ার স্বাভাবিক উপায়। আইডেম্পোটেন্সি ছাড়া অর্ডার তৈরির জন্য — এটি ডুপ্লিকেটের উৎস। টাস্কের আইডেন্টিফায়ার বা অপারেশনের পৃথক কী চূড়ান্ত হ্যান্ডলার পর্যন্ত পাঠাতে হবে, সরবরাহকারীর কাছে অর্ডার পাঠানোর মডিউলসহ।
পুনরায় সরবরাহ বন্ধ করার অসুবিধা হলো — ওয়ার্কার ব্যর্থ হলে অর্ডারের কিছু অংশ হারিয়ে যেতে পারে। সম্ভাব্য পুনরাবৃত্তি গ্রহণ করা এবং হ্যান্ডলারকে সেগুলোর প্রতি সহনশীল করা নিরাপদ।
প্যানেল এবং সরবরাহকারীর মধ্যে ডুপ্লিকেট দেখা দেয়
অভ্যন্তরীণ অর্ডার একবার তৈরি হতে পারে, কিন্তু বাহ্যিক API-তে অনুরোধ দুইবার পাঠানো হয়। কারণ একই: প্যানেল সরবরাহকারীর কাছ থেকে উত্তর পায়নি এবং পাঠানো পুনরাবৃত্তি করার সিদ্ধান্ত নিয়েছে। যদি সরবরাহকারী প্রথম অনুরোধ গ্রহণ করে থাকে, তার দিকে দুটি একই রকম আবেদন দেখা দেবে।
অভ্যন্তরীণ অর্ডারের সাথে বাহ্যিকের পৃথক সংযোগ প্রয়োজন: পাঠানোর আইডেন্টিফায়ার, আইডেম্পোটেন্সি কী বা সরবরাহকারীর সংরক্ষিত উত্তর। এটি ধরে নেওয়া যায় না যে নিজের প্যানেলে প্রবেশে সুরক্ষা স্বয়ংক্রিয়ভাবে বহির্গামী কলগুলো সুরক্ষিত করবে।
তৃতীয় পক্ষের API-এর সাথে মিলনের অসুবিধা হলো — প্রতিটি সরবরাহকারী বাহ্যিক কী দ্বারা অনুসন্ধান সমর্থন করে না। তখন পাঠানোর প্রচেষ্টা রেকর্ড করতে হয় এবং অনির্দিষ্ট স্ট্যাটাসগুলো পৃথকভাবে বিশ্লেষণ করতে হয়।
ওয়েবহুক নতুন অর্ডার তৈরি করা উচিত নয়
ওয়েবহুক পরিবর্তন সম্পর্কে জানায়: অর্ডার গৃহীত, চালু, সম্পন্ন, বাতিল বা যাচাই প্রয়োজন। ত্রুটি দেখা দেয় যখন ওয়েবহুক হ্যান্ডলার বিজ্ঞপ্তিকে নতুন করে অর্ডার তৈরির নির্দেশ হিসেবে গ্রহণ করে।
একই ওয়েবহুক পুনরায় আসতে পারে। প্রেরক সরবরাহ পুনরাবৃত্তি করে যদি নিশ্চিতকরণ না পায়, এবং বিজ্ঞপ্তিগুলো কখনও কখনও ক্রম অনুযায়ী আসে না। হ্যান্ডলারকে বাহ্যিক আইডেন্টিফায়ার দ্বারা বিদ্যমান অর্ডার খুঁজে বের করতে এবং স্ট্যাটাস আপডেট করতে হবে।
শুধুমাত্র গ্রহণের সময় অনুযায়ী ওয়েবহুক প্রক্রিয়াকরণের অসুবিধা হলো — দেরিতে আসা বিজ্ঞপ্তি বর্তমান স্ট্যাটাসকে পুরনো দিয়ে ওভাররাইট করতে পারে। ইভেন্ট আইডেন্টিফায়ার, স্ট্যাটাস সংস্করণ বা স্পষ্ট রূপান্তর নিয়ম প্রয়োজন।
কোন রেকর্ডগুলো ডুপ্লিকেটের উৎস খুঁজে পেতে সাহায্য করবে
তদন্তের জন্য শুধুমাত্র দুটি অর্ডার নম্বর দেখা যথেষ্ট নয়। প্রক্রিয়াকরণের প্রতিটি ধাপ সম্পর্কে ডেটা প্রয়োজন: অনুরোধের সময়, আইডেম্পোটেন্সি কী, ক্লায়েন্ট আইডেন্টিফায়ার, অর্ডার প্যারামিটার, ব্যাকগ্রাউন্ড টাস্ক নম্বর, বাহ্যিক API প্রতিক্রিয়া এবং পুনরায় পাঠানোর প্রচেষ্টা।
- ডুপ্লিকেটগুলো অপারেশন কী দ্বারা মিলান, শুধুমাত্র লিঙ্ক দ্বারা নয়;
- ইনকামিং API লগে একই রকম অনুরোধ ছিল কিনা পরীক্ষা করুন;
- কিউতে টাস্ক পুনরাবৃত্তি হয়েছিল কিনা দেখুন;
- অভ্যন্তরীণ অর্ডার তৈরি এবং সরবরাহকারীর কাছে পাঠানো আলাদা করুন;
- উত্তর পাওয়ার সাথে সাথেই আবেদনের বাহ্যিক আইডেন্টিফায়ার সংরক্ষণ করুন।
অত্যধিক সংক্ষিপ্ত লগের অসুবিধা হলো — সমস্যার উৎস বিশ্লেষণের আগেই অদৃশ্য হয়ে যায়। অত্যধিক লগিংয়ের অসুবিধা হলো — রেকর্ডে টোকেন, ব্যক্তিগত ডেটা এবং অন্যান্য সংবেদনশীল ক্ষেত্র পড়তে পারে, তাই সেগুলো মাস্ক করতে হবে।
অনুরোধের অনির্দিষ্ট ফলাফল কীভাবে পরিচালনা করবেন
টাইমআউটের পরে নতুন ডেটা দিয়ে সাথে সাথে অর্ডার পুনরায় তৈরি করা যায় না। প্রথমে API-কে আইডেম্পোটেন্সি কী বা ক্লায়েন্ট আইডেন্টিফায়ার দ্বারা অপারেশন পরীক্ষা করতে হবে। যদি অর্ডার পাওয়া যায়, এর বর্তমান অবস্থা ফেরত দেওয়া হয়। যদি প্রক্রিয়াকরণ এখনও চলছে, ক্লায়েন্ট অপেক্ষার স্ট্যাটাস পায়।
- প্রথম অনুরোধের আগে অপারেশন কী তৈরি করুন।
- প্রতিটি পুনরাবৃত্তিতে একই কী পাঠান।
- একটি সুরক্ষিত ডেটাবেস অপারেশনে কী এবং অর্ডার সংরক্ষণ করুন।
- কিউ এবং বাহ্যিক API-তে অপারেশন আইডেন্টিফায়ার পাঠান।
- পুনরায় অনুরোধের সময় আগে তৈরি অর্ডার ফেরত দিন।
এই পরিস্থিতির জন্য API এবং ক্লায়েন্ট ইন্টিগ্রেশনে উন্নতি প্রয়োজন। এর অসুবিধা হলো — ডিবাগিং আরও কঠিন এবং অর্ডারের বেশি স্ট্যাটাস, তবে অনুরোধের পুনরায় সরবরাহ স্বয়ংক্রিয়ভাবে পুনরায় ক্রয় বোঝানো বন্ধ করে।
Last Articles
ডিজাইন এবং ফাংশনে কী পরিবর্তন হয়েছে আমরা সাইটটি আপডেট করেছি যাতে এটির সাথে কাজ করা দ্রুত এবং আরও সুবিধাজনক হয়। প্রধান পরিবর্তনগুলি ইন্টারফেস, ব্যক্..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. আমাদের সকল দর্শকের জন্য ১৫% ছাড় পেতে "December2025" প্রোমো কোড ব্যবহার করুন2. আমরা ১ জানুয়ারি পর্যন্ত আমাদের কনফিগারেটর এবং সবচেয়ে সাশ্রয়ী মূল্..
টুইচ পরিষেবাগুলি হল স্থিরভাবে কাজ করা, তাই আমরা স্কোয়াড, রিসেলারদের সাথে সহযোগিতা করতে প্রস্তুত, সেবা মালিকদের, বট মালিকদের, এবং অনেক অন্যদের.টেল..
আমরা আমাদের টুইচ ভিউয়ার পরিষেবাগুলি সম্পূর্ণরূপে আপডেট করেছে এবং তারা এখন স্থিরভাবে কাজ. আমরা শুধুমাত্র দর্শকদের জন্য উচ্চ মানের আইপি ঠিকানা ব্যব..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
অংশীদারিত্ব পরিষেবা এবং রেফারেল প্রোগ্রামের ব্যাপক জনপ্রিয়তার কারণে, আমরা একটি সহযোগিতা টেবিল তৈরি করেছি। সারমর্মটি খুব সহজ: আরও লাইভ দর্শক - আমাদের ..
স্ট্রিমারদের জন্য আমাদের পরিষেবা
Dlive
Bigo
কন্টেন্ট ক্রিয়েটরদের জন্য আমাদের পরিষেবা
